Every restaurant weighing up its own ordering app starts with the commission, and the commission is the smaller half of the trade. The larger half is that the marketplace has the customer. They know who orders what, how often and at what time. You know that an order arrived.
Building your own ordering app is not primarily a way to avoid commission. It is a way to own the repeat customer, and it only pays back if you actually have repeat customers. That distinction decides whether this is a good investment or an expensive lesson, and it is worth settling before anyone talks about features.
The marketplace trade-off, fairly
It would be easy to be one-sided here, so the honest version. Marketplaces are genuinely good at something difficult: they put you in front of people who have never heard of you, at the exact moment those people have decided to order food. That is expensive demand and they generate it constantly. They also handle payment, disputes, and a driver network you would struggle to replicate.
What you give up is margin on every order, the customer relationship, and the ability to talk to anyone directly. A first-time customer discovered through a marketplace has real value. The same customer ordering for the twentieth time through a marketplace is you paying discovery costs on a person who already knows exactly what they want.
So the sensible position is not to leave. It is to keep the marketplace for discovery and move the regulars somewhere you own. Most restaurants that do well with an app run both, deliberately.
When your own app pays back
The arithmetic is straightforward and worth doing on paper before committing to anything.
- Enough repeat ordering. If most of your orders come from people ordering once, an app will not be installed and would not help if it were. Regulars are the whole case.
- Enough volume that the commission is a real number. Work out what a year of commission on your repeat orders comes to. If that figure is smaller than the build plus a year of running it, stop here.
- Something worth opening the app for. A saved order, a loyalty balance, an accurate time. Without one of those, people will use whichever route is fewest taps, and that is usually the marketplace already on their phone.
- A kitchen that can absorb the orders. An app that generates orders you cannot make on time damages the thing it was meant to protect.
- Someone to run it. Menus change, prices change, items sell out. If nobody owns keeping it current, it will be wrong within a month and wrong is worse than absent.
What a restaurant ordering app has to do well
Not a feature list. These four decide whether it gets used twice.
- Reorder in two taps. The single most important thing in the entire product. Your regulars order roughly the same thing, and the app that lets them repeat last Friday's order without rebuilding it will beat any marketplace on convenience. If reordering takes as long as ordering fresh, you have built a worse version of a website.
- Timing you can stand behind. Not an optimistic estimate. If it says twenty-five minutes it needs to be twenty-five minutes, because an app that is wrong about time is worse for trust than a phone call that made no promise. Better to quote longer and be right.
- Payment that is already saved. Saved card, wallet payment, one confirmation. Every extra step at this point loses orders, and this is where a poorly built app leaks most.
- Loyalty that is visible. The reason to use yours rather than theirs. It has to be simple enough to explain in one sentence and visible enough that people notice progress.
Notice what is not on that list: a menu that looks beautiful, a story about your ingredients, a booking feature. All fine, none of them the reason anyone installs an ordering app.
The kitchen is where these fail
The failure we see is not technical. The app works, orders arrive, and the kitchen now has a tablet next to two other tablets and a printer, and somebody has to watch all of them on a Friday night.
- Into the same system as everything else, if you have a point-of-sale that accepts orders. One queue, one screen, one place to look.
- Printing to the same printer as your other channels, if it does not. Unglamorous and it works.
- A way to mark items unavailable in seconds, from wherever the staff are standing. If marking something sold out is a five-minute job on a laptop in the office, it will not happen, and you will be selling something you cannot make.
- A way to pause ordering when the kitchen is under water, without anyone needing to ring a supplier.
- Someone testing it during a real service, before launch. A kitchen at seven on a Saturday is a different environment from a demonstration.
Start with a web page, not an app
This is the advice we give most often and it is the smaller job for us. Before building an app, build an ordering page on your own website, and make it good.
It works for everybody immediately, with nothing to install, and no store review to wait for. You can put the link on your receipts, your packaging, your window and your social accounts. You can add saved orders and a loyalty scheme. Modern web pages can be installed to a home screen and send notifications, which covers a large share of what people imagine an app is for. And it costs a fraction of a native app.
Then look at your numbers after three months. If people are ordering repeatedly through that page, you have proved the case for an app with real evidence rather than optimism, and you will know exactly what it needs to do. If they are not, you have saved yourself a great deal of money. Do you need an app or a website walks through that decision properly, and the ordering page itself is e-commerce work rather than an app project.
Getting people onto it
The app is the easy part. Persuading a regular to change how they order, when the marketplace app is already on their phone and already knows their card, is the actual project, and it is where budgets are usually not spent at all.
- Put it in the bag. A card in every delivery, every single time, saying where to order next. The people receiving your food are exactly the audience, and this is the cheapest channel you will ever have.
- Make the first direct order clearly better. A discount, a free side, something with a deadline. You are buying a habit change, and habit changes need a reason to happen this week rather than eventually.
- Ask at the counter. For anyone ordering in person, thirty seconds of a real person explaining it converts far better than any campaign.
- Do not fight on the marketplace's own ground. You will not win on selection or on drivers. Win on price, on knowing the customer, and on the reorder being faster.
- Give it a reason to stay installed. A loyalty balance that is visibly progressing is the most reliable one. An app that does nothing between orders is the first thing deleted when storage runs low.
Budget for this alongside the build rather than after it. A well-built ordering app with no adoption plan is a common and expensive outcome, and the restaurants that do well with one treated the marketing as half the project from the start.
What it costs
| Route | Illustrative cost | Ongoing |
|---|---|---|
| Ordering page on your own site | $8,000 to $25,000 | Hosting and payment fees |
| Ordering page published as an installable app on both stores | $15,000 to $40,000 | The above plus developer accounts |
| A native app built from scratch | $50,000 to $150,000 and up | The above plus two codebases to maintain |
| An off-the-shelf ordering product | $50 to $400 a month | Subscription, sometimes plus a per-order fee |
Illustrative ranges from the kind of work we quote, not a price list. The last row is a serious option and worth checking before commissioning anything, particularly for a single site. If you do build, app store launch is the part people underestimate, because a first submission normally takes at least one rejection round.
Not for you if
One number settles most of this. Work out what share of last month's orders came from someone who had ordered before. If it is small, fix that first, because an app cannot create loyalty that does not exist. If it is large, you already have the thing an app is designed to protect.
