The choice is not “cheap template” versus “serious software.” It is speed and ownership versus bespoke control. Both can own the code; only one can launch before the next quarter.
| White label (Foodomaa) | Custom build | |
|---|---|---|
| Up-front | $299 once | $15,000–$60,000+ |
| Time to launch | Days–weeks | 3–9 months |
| Source code | Included | Included |
| Branding | Logo, colours, domain, app name | Unlimited |
| Novel workflows | Edit the source or hire a developer | Built from scratch |
| Maintenance | You or your agency | You or your agency |
| Best for | A proven delivery model, launched fast | A genuinely novel operation |
When white label wins
- You need to test demand before spending five figures.
- Your model is standard: restaurants, menus, zones, riders, commission.
- You want the source code and the ability to customise later.
- You have a developer or agency for branding and integrations.
When custom wins
- Your routing or dispatch logic is the product.
- You need a brand experience that cannot be configured.
- You have a funded team and six months before launch.
- You are integrating unusual hardware, compliance or logistics.
The hidden cost of “cheap” custom
Custom software is not finished at launch. Maintenance, hosting, security patches, app-store updates and feature requests continue every month. A $299 licence plus a $12 VPS is not the same category of spend as a $40,000 build; the point is to spend the difference on restaurants and riders, not code.
See the white label food delivery app page or read the Foodomaa review.
What a white-label licence actually includes
“White label” is used loosely. In a food delivery context it usually means you can replace the vendor's brand with your own across the customer app, restaurant app, rider app, admin panel and website. It does not automatically mean you can resell the software, host it for other restaurants, or hand it to a client as their own product. Those are separate licence rights.
A practical white-label package should include the customer app, restaurant/vendor app, rider app, admin panel, website, source code, installation documentation and a defined support window. Ask which of those are included in the price and which are add-ons. The app bundle identifiers matter too: Apple and Google treat each branded app as a separate listing, even if the code is the same.
| Included item | Why it matters | Question to ask |
|---|---|---|
| Customer app | The ordering experience | Can we publish under our own bundle ID? |
| Restaurant app / panel | Order acceptance and menu control | Is the app included or an add-on? |
| Rider app | Dispatch and delivery proof | Does it support our zone and cash rules? |
| Admin + website | Commissions, payouts, content | Can we remove all vendor branding? |
| Source code | Customisation and exit | Is it readable, and what does the licence allow? |
| Installation + support | Time to first order | What is covered, and for how long? |
The agency and reseller question
Agencies often buy a white-label licence, build for a client and hand over the deployment. That can work, but the licence must allow it. Decide early who owns the licence, the domain, the app-store accounts, the payment accounts and the customer data. The cleanest structure is usually: the client buys the licence in its own name; the agency charges for implementation and support; the client owns the deployment.
If the agency holds the licence, the client is effectively renting access. Put that in writing, including what happens if the agency closes or the client wants to move to another developer. A white-label product is not a trademark transfer, and it is not a reseller programme unless the vendor says so explicitly.
A 30-day white-label launch sequence
- Days 1–3: buy the correct licence, provision the server, point the domain and install SSL.
- Days 4–7: replace logo, colours, app name, package IDs, email sender and legal pages.
- Days 8–12: configure zones, commissions, taxes, delivery fees and payment gateways.
- Days 13–17: load 25–40 restaurant menus with photos, prep times and availability.
- Days 18–22: build and sign the apps; run a full order, refund and rider test.
- Days 23–27: publish to internal/closed testing; train the support team.
- Days 28–30: soft-launch one dense zone and monitor every order manually.
The sequence assumes a standard menu and a developer or agency. If you are translating the interface, add a native review before the soft launch. A translated checkout that reads badly will cost more orders than a plain English one.
Where white label breaks
White label is a poor fit when the delivery operation itself is the product. If your routing algorithm, dark-store model, packaging system or compliance workflow is the differentiator, a standard product will become a constraint. The same is true if you need deep integration with unusual hardware, a proprietary POS or a regulatory process the vendor has never seen.
It is also a poor fit if you have no one to own the deployment. A licence gives you control, but control is work: updates, backups, payment changes, app-store releases and support. If nobody owns those tasks, a managed SaaS may be the more honest choice, even at a higher monthly cost.
The decision scorecard
| Question | White label | Custom |
|---|---|---|
| Launch in under 8 weeks | Yes | Rarely |
| Budget under $10,000 | Usually | No |
| Need a novel dispatch or routing model | Constrained | Yes |
| Want to own the code and data | Yes | Yes |
| Have a developer or agency | Recommended | Required |
| Can maintain the platform | Yes, with a plan | Yes, with a team |
Score each row for your business. If white label wins most rows, buy the licence and spend the difference on restaurants, riders and marketing. If custom wins the operational rows, do not pretend a template can carry a genuinely novel model.
What it costs to launch white label
The licence is only one line. A realistic white-label launch budget includes installation, branding, app publishing, payment integration, menu migration, training and the first month of support.
| Item | Indicative range | Notes |
|---|---|---|
| Licence | $299 | Foodomaa one-time |
| Hosting / domain / SSL | $50–$200/year | VPS and domain |
| Branding and app assets | $200–$2,000 | Logo, colours, screenshots |
| Installation and configuration | $200–$2,000 | Zones, gateways, menus |
| App-store accounts | $25 + $99/year | Google Play + Apple |
| Launch support | $0–$1,000 | First month, depending on team |
A custom build with the same scope commonly starts at $15,000 and can exceed $60,000. The gap is not just code; it is the product management, QA and maintenance you avoid by starting from a working baseline.
Contract clauses that matter
- Installations: how many production and staging domains are allowed.
- Client work: whether an agency can charge a client for the build.
- Resale: whether you can host for third parties or sell the software.
- Source code: what is included and whether it is obfuscated.
- Support: what is covered, for how long and at what response time.
- Exit: what happens if you change developers or stop trading.
A three-year cash example
White label: $299 licence + $1,500 implementation + $30/month hosting + $500/year support = roughly $3,000 over three years. Custom: $30,000 build + $6,000/year maintenance + hosting = roughly $48,000. The custom build may be worth it for a novel operation, but the difference buys a lot of restaurant recruitment and rider capacity.
When to move from white label to custom
Move when the product's data model, dispatch rules or compliance requirements genuinely cannot express your business. Do not move because a stakeholder wants a different colour on a button. A custom build is a permanent maintenance commitment; start with the licence, prove demand and only rebuild the parts that create a measurable advantage.
The handover checklist
The end of a white-label project is not “the site is live”. You should receive an asset pack that lets you operate without the person who built it. Ask for this list before the final payment, not after.
| Asset | What good looks like |
|---|---|
| Server and domain | Accounts in your name, DNS access, SSL renewal owner and a documented hosting plan |
| Source code | A repository you can access, with the deployed branch tagged and a README |
| Database | A current dump, restore instructions and the backup schedule |
| App accounts | Play Console and Apple Developer accounts owned by you, with signing keys and certificates |
| Payment accounts | Merchant accounts in your legal entity, with live keys stored in a password manager |
| Integrations | Maps, SMS, email, push and analytics accounts, plus who pays for each |
| Runbook | Deploy, rollback, backup restore, cron, queue restart and incident contacts |
| Credentials | Handed over securely, rotated after the handover, never left in a chat |
If the agency owns the app-store accounts or the payment merchant account, you do not control the product. Fix that before launch. Moving an app to a new owner later is possible, but it costs time and can lose reviews and installs.
Who owns maintenance after launch?
A white-label licence transfers code, not responsibility. Someone still has to patch PHP and the framework, renew SSL, monitor disk, update payment APIs, rebuild the apps for new OS versions and answer support tickets. Decide whether that is an in-house developer, the agency or a retainer.
A realistic care plan covers security updates, uptime monitoring, backups, gateway changes and a monthly block of small fixes. It should not promise unlimited features. Ask for the response time, the escalation path and what happens if a payment gateway changes its API. A platform that cannot take money is down, even if the website loads.
Budget maintenance as a monthly line, not a surprise. Ten to twenty percent of the original build cost per year is a common planning range; a complex custom build sits at the higher end. A white-label deployment is usually cheaper to maintain because the core is shared, but you still own the server and the integrations.
Red flags in a white-label demo
- Only a video, no live login. You cannot test dispatch, refunds or settlements from a video.
- “Unlimited customisation included”. Customisation has a scope; unlimited is not a scope.
- No named licence terms. “White label” without a document is a marketing phrase.
- Apps shown but not included. Confirm whether the price covers customer, vendor and rider builds.
- No test payment. A checkout that only shows a success screen has not proven the callback.
- Vendor branding you cannot remove. Check the footer, emails, app splash and invoices.
- No export path. Ask how you would leave with customers, menus, orders and settlements.
Run the same test script on every demo: create a vendor, add a menu item, place an order, accept it, assign a rider, complete delivery, refund it and read the settlement report. A product that cannot finish that loop is a prototype.
How to compare a white-label quote with a custom quote
Compare three years, not the first invoice. A custom quote may look complete but exclude app-store publishing, maintenance, hosting and the second round of changes. A white-label quote may look cheap but exclude branding, translation, payment integration and launch support.
| Cost line | White label | Custom build |
|---|---|---|
| Licence or build | $299–$2,000 | $15,000–$80,000+ |
| Branding and setup | $500–$5,000 | Included or extra |
| Payment integration | Often standard | Scoped per gateway |
| Apps and store publishing | Build included; accounts yours | Usually extra |
| Year-one maintenance | $1,000–$6,000 | $3,000–$15,000+ |
| Major change | Plugin or custom patch | New development cycle |
| Exit cost | Low: you hold the code | Low: you funded the code |
The cheapest three-year option is not always the lowest first invoice. Add implementation time, the cost of waiting three extra months and the risk of a build that misses the launch window. For a standard food-first operation, the licence usually wins on time and cash. For a genuinely novel operating model, the custom build can be the cheaper decision over three years because it avoids workarounds.
The scope document that prevents disputes
Write a one-page scope before the contract. It should list every surface, every integration and every handover item, with a clear “included” or “not included” next to each. Ambiguity is where white-label projects become expensive.
- Surfaces: customer web, customer app, vendor panel, vendor app, rider app, admin, landing pages.
- Branding: logo, colours, typography, email templates, invoices, app icons and splash screens.
- Integrations: payment gateways, maps, SMS, email, push, analytics and any POS or accounting link.
- Content: menu import, photography, translations, legal pages and support scripts.
- Launch: server setup, SSL, app-store submission, test orders and go-live support.
- Handover: repository, database dump, accounts, credentials and runbook.
Attach the scope to the invoice. If a change appears later, price it separately instead of arguing about whether it was “part of the platform”. A written scope protects the buyer and the agency.