Restaurant ordering app vs delivery aggregators: when your own app makes sense

An own app wins back regulars, not strangers

Aggregators do two jobs. They bring you customers who have never heard of you, and they handle the ordering and often the delivery. Your own app can only do the second job well.

Nobody searches an app store for your restaurant before they know it. People install your app after they have eaten your food and want it again. So the useful question is how many of your current orders come from people who would order from you directly if it were just as easy. I call those moved orders. They are the only orders the break-even maths should count.

This is also why I would rarely tell a restaurant to leave the aggregators. They are your discovery channel. The own app is a second channel for the customers you already won.

My decision rule, as a checklist

Answer these from your own records before asking anyone for a quote. If you cannot tick the first three, I would wait.

• Repeat customers: you can see, from your aggregator reports or your own records, that a real share of orders comes from the same people week after week.
• Fulfilment: you can handle pickup, or delivery with your own riders, without the aggregator's fleet.
• A margin per moved order: what you pay the aggregator on an order, minus your own payment fee and any app-only discount, leaves a positive number.
• Payback: moved orders a month, multiplied by that margin, minus your monthly running costs, pays back the build within a period you are comfortable with.
• Someone to run it: a person who updates the menu, answers app customers and handles refunds.
• A reason to install: a loyalty reward, a regulars' menu or faster pickup, so customers have a reason to keep a second app.

A worked break-even example with sample numbers

Every order figure below is made up for illustration. They are not market rates and not from any restaurant. Replace each one with your own numbers from your aggregator statement and your quotes. Only the build price is real: Growth at $1,699.

Start with the margin on one moved order. Read your own statement and work out what the aggregator costs you on a typical order. In this example that is $5. Your payment gateway charges you something on a direct order, say $1. You give app customers a small discount to switch, say $1. Margin per moved order: $5 minus $1 minus $1, which is $3.

Now the monthly running costs. Hosting, the payment provider's monthly fees, store accounts and maintenance are not in my package price, so add your real quotes. In this example they total $150 a month.

• Orders just to cover running costs: $150 divided by $3 is 50 moved orders a month. Below that, the app loses money every month.
• Scenario A, 300 moved orders a month: 300 times $3 is $900, minus $150 leaves $750 a month. $1,699 divided by $750 is a little over two months to pay back the build.
• Scenario B, 60 moved orders a month: 60 times $3 is $180, minus $150 leaves $30 a month. Payback takes more than four years, which I would not recommend.
• Scenario C, your numbers: margin per moved order, running costs a month, and a realistic count of moved orders. Do the same three lines.

What changes the build price

Delivery is the big one. Pickup, or delivery by your own riders who read orders from a staff screen, fits an ordering app. Live rider tracking, a driver app and dispatch turn it into three products, and my post on delivery app cost explains why that sits on Scale at $2,500 or beyond.

Payments are the second. Food is a physical good, so Apple's guideline 3.1.3(e) and Google Play's payments policy both require a card gateway, Apple Pay or similar rather than in-app purchase. One provider with a simple flow fits a package. Several providers, wallets or split payouts count as a complex payment gateway and are quoted separately.

The third is your kitchen. If app orders must land in your POS and kitchen display, deducting recipe stock as they go, that is restaurant POS and kitchen software, a fixed-quote build rather than a package.

The package I would start a restaurant on

Growth at $1,699, up to 25 screens: a branded Flutter app for Android and iOS with its own Node.js backend and PostgreSQL database, menu, ordering, one payment flow if scoped, order history and admin tools to manage the basics. Launch at $999 suits a restaurant that already has an ordering system with an API and wants an app on top of it. Scale at $2,500 adds a full admin dashboard, integrations and push notifications where supported.

Third-party fees, hosting and maintenance are not included. Send me your margin per order and your rough count of regulars, and I will tell you whether I think the numbers work before quoting anything.