By Devfood Team — who we are
White-Label Online Ordering, Explained
What white-label ordering actually means, which parts are genuinely yours, why the app store listing is the hard part, and when a marketplace wins.
White-label online ordering is a system a restaurant uses under its own name — its domain, its logo, its app in the stores, its customer list — while somebody else builds and runs the software underneath. The customer sees the restaurant. The restaurant sees a subscription instead of a commission.
The term is used for at least three different arrangements, and they are not equally white-label. Knowing which one a vendor is selling is most of the evaluation.
Three things sold as “white label”
A branded page on the vendor’s domain. Your logo, your colours, at yourvendor.com/your-restaurant. This is the weakest form and the most common at the free end. The address bar says somebody else’s name, the SEO accrues to them, and a customer who bookmarks it has bookmarked the vendor.
A branded site on your own domain. Your logo and your domain, with the vendor’s software behind it. This is what most people mean, and it is a genuine step up: the link a customer shares is yours, and search traffic lands on your name.
Branded apps in your own store listings. Your restaurant’s name in the App Store and Google Play, published under your developer account or one held for you. This is the strongest form and the one with the most operational weight behind it — which is why it is where vendors differ most.
Devfood is the third kind: web ordering on your domain plus native customer and driver apps published under your brand. That is worth stating plainly because the word alone does not distinguish it.
What is actually yours, and what only looks yours
The useful question is not “is it branded” but “what survives if you leave”.
Your domain, and this is the real prize. If the ordering flow lives on your own domain, the links, the search results and the bookmarks are yours permanently. Move vendors and you keep them. On a vendor subdomain you are renting all three, and the rent is due when you switch.
Your customer list. Names, emails, phone numbers, order history. Ask directly whether you can export it, in what format, and whether you can do it yourself without asking. A list you have to request is a list you do not really hold.
Your payment relationship. Whether the money lands in your account or the vendor’s, and who is the merchant of record, changes what happens during a dispute and what happens if the vendor fails. Restaurants routinely discover this at the worst moment.
Your app store listing. More on this below, because it is not the box-tick it appears to be.
What only looks yours is the software itself. You are licensing it, and that is fine — but it means the roadmap is not yours, and a feature you need is a request rather than a decision. Pretending otherwise leads to the wrong expectations about turnaround.
Why the app store listing is the hard part
Vendors say “branded apps” as though it were a colour change. Three things make it the most operationally loaded part of the arrangement:
Somebody has to own the developer account. If it is the vendor’s, your app sits inside their account and moves with their relationship to Apple and Google, not yours. If it is yours, you need the account, the legal entity behind it, and someone to hold the credentials — and that is a real task, not a form.
Apple rejects template apps. Guideline 4.3 exists precisely to stop one codebase being shipped a thousand times with a new logo. A vendor doing this at scale has to have an answer, and “we have never had a problem” is not one. Ask what the answer is.
Updates are a release process, not a deploy. A web change is live when it is pushed. A native app change waits on review, then on customers updating. Anything you plan to change often should live on the web side.
What to ask a vendor
Five questions that separate genuinely white-label products from a branded skin:
- Whose domain does the ordering flow run on, and whose name is in the address bar at checkout? Some products are white-label until payment and then are not.
- Can I export my full customer list myself, today, without asking? Ask to see the button.
- Who is the merchant of record, and whose bank account receives the order? Then ask what happens to a chargeback.
- Whose developer account holds the app, and what is your answer to Apple’s 4.3 guideline? A vendor shipping branded apps at scale has thought about this or has been lucky.
- What does leaving look like? Specifically: my domain, my list, my app listing, my historical orders. The answer to this is the honest measure of how white-label the product is.
When a marketplace is the better answer
White-label is a distribution decision, not an upgrade, and it is the wrong one more often than vendors selling it suggest.
Marketplaces sell discovery. If most of your orders come from people who did not know your restaurant existed, a system that only serves people who already do will not replace them — it will sit alongside them, and the honest plan is to run both while shifting your repeat customers across.
If you have no way to tell customers the new ordering link exists — no signage, no receipt inserts, no list, no counter traffic — then a direct channel has no audience on day one, and the subscription starts before the orders do.
And if your order volume is low enough that a commission costs less than a subscription, the arithmetic simply favours the commission for now. That crossover is worth calculating rather than assuming; it moves as you grow, and the point at which it flips is the point to revisit this.
Where it does work, it works because the second order from the same customer costs you nothing in commission — and every order after that compounds. That is the entire case, and it is a case about repeat business rather than about software.
If you are costing this out for a single site, the pricing page sets out what a location costs in your region, and Do You Need the In-Store Suite on Day One? covers what you can safely leave until later.