Almost every restaurant owner who contacts us about apps for restaurants UK wide opens with the same sentence: the delivery platforms are taking too much. That is a fair reason to look at building your own ordering channel, and it is also the reason a lot of restaurant apps get built badly, because the decision is made on frustration rather than on numbers. An app can genuinely take you off the commission treadmill. It can also sit at 40 downloads and a £22,000 invoice. The difference is almost never the design. It is whether the volume was there in the first place, and whether the app was built around repeat ordering instead of around a menu PDF with a payment button bolted on.
This guide gives you the real cost bands we quote in Britain in 2026, what each band actually buys, and the payback arithmetic you should run before anyone writes a line of code.
What do apps for restaurants UK operators buy actually cost?
Apps for restaurants UK operators commission fall into three broad bands. A single site ordering and loyalty app costs roughly £8,000 to £20,000. A multi site app with table booking, a kitchen dashboard, and live order tracking costs roughly £25,000 to £60,000. Anything with its own courier dispatch logic starts above that. On top of the build, expect £150 to £600 a month in running costs.
Those ranges are wide because restaurants ask for very different things under the same word. One owner means “customers can order a pizza from their phone”. Another means “customers order, the kitchen printer fires, the driver gets dispatched, and loyalty points post automatically across six sites”. Both are restaurant apps. They are not remotely the same piece of software, and pretending they are is how founders end up comparing a £9,000 quote to a £45,000 quote and assuming one of them is trying it on.
The three cost bands in detail
| Band | Typical cost | What it includes | Who it suits |
|---|---|---|---|
| Essential | £8,000 to £20,000 | Menu, basket, card payment, order status, push notifications, simple stamp loyalty, one site | Independents and single site operators with existing repeat trade |
| Growth | £25,000 to £60,000 | Everything above plus table booking, multi site menus and pricing, kitchen or admin dashboard, tiered loyalty, order scheduling, EPOS integration | Small groups, 2 to 10 sites, or a single high volume site |
| Operations | £60,000 upwards | Own driver dispatch, live map tracking, stock aware menus, franchise controls, deep back office integration | Groups running their own delivery fleet |
Most independents we speak to belong in the Essential band and are being quoted for the Growth band, usually because the conversation started with features rather than with the commercial goal. If your objective is to stop paying commission on the orders you already get from regulars, you do not need a dispatch engine. You need somebody to be able to reorder their usual in under thirty seconds.
What the delivery platforms actually cost you
The commission you are trying to escape is the whole business case, so it is worth being precise about it. In the UK, aggregator commission depends heavily on who does the delivering. Uber Eats publishes its UK rates at 30 per cent when Uber delivers, and 13 per cent when you deliver or the customer collects. Just Eat and Deliveroo do not publish equivalent tables, and industry comparisons put their effective rates between roughly 14 and 35 per cent depending on the plan and whether the platform supplies couriers.
Three things get forgotten when owners do this sum on the back of a napkin. VAT applies to those fees. There are usually per order admin charges sitting underneath the headline percentage. And paid promotion inside the app, which most sites end up buying to stay visible, is an additional cost that does not appear in the commission line at all. The effective rate is therefore almost always higher than the number in the contract.
The honest counterpoint is that platforms deliver something your app never will, which is discovery. They put you in front of people who have never heard of you. Your own app reaches people who already like you. That distinction is the key to the entire decision, and it is why the sensible strategy for most sites is not to leave the platforms but to move the repeat customers off them.
The payback maths, run properly
Here is the calculation that should decide this, using a worked example rather than a principle.
Say your average order value is £28 and your blended platform commission, including fees and VAT, is an effective 27 per cent. Every order that moves from the platform to your own app saves you £7.56 in commission. Against that, your own app still costs you card processing, which for a UK app taking payments through Stripe is a small percentage plus a fixed pence amount per transaction, so call the real saving £6.90 per order.
Now assume an Essential band build at £14,000, plus £250 a month in running costs, so £17,000 across the first year. To recover that in twelve months you need roughly 2,464 orders through your own app, which is about 47 orders a week.
| Own app orders per week | Annual commission saved | Year one position on a £17,000 build |
|---|---|---|
| 20 | £7,176 | Loss of £9,824 |
| 40 | £14,352 | Loss of £2,648 |
| 47 | £16,863 | Roughly break even |
| 75 | £26,910 | Profit of £9,910 |
| 120 | £43,056 | Profit of £26,056 |
Change the inputs and the answer changes, which is the point. A site with a £45 average order value breaks even at half the volume. A site with £16 average orders needs almost double. Run the numbers with yours before you run them with anyone else’s, and be conservative about how many of your platform customers will actually switch, because that migration is the single most over optimistic assumption in every restaurant app plan we have reviewed. A realistic first year figure is that you convert perhaps a quarter to a third of your genuine regulars, not “everyone who has ever ordered”.
The features that pay for themselves, and the ones that do not
After building and reviewing a fair number of these, the pattern is consistent. Four things drive the return.
Reorder in one tap. The single highest impact feature in any restaurant app. A returning customer should reach checkout in two screens with a saved card and a saved address. Every extra step costs you orders.
Push notifications, used sparingly. This is the actual reason to have an app rather than a website. A Thursday afternoon message to people who have ordered before is the cheapest marketing channel a restaurant will ever own. It is also the fastest way to get uninstalled if you send three a week.
Loyalty that is visible on the home screen. Digital stamps work because progress is motivating. Someone at seven stamps out of ten will choose you over the place next door. Keep it simple, and make the progress bar impossible to miss.
Scheduled ordering and collection slots. Collection orders carry no delivery cost and no commission at all, and a surprising share of customers prefer them. Sites that make collection prominent tend to see it become the most profitable order type they have.
What consistently does not earn its cost in a first version: an in app table plan, a review feed, a blog, gamified spinning wheels, and any kind of social sharing. They add development cost, add screens to maintain, and rarely change behaviour. Build them later if the data asks for them.
Where the timeline and the money actually go
A focused Essential build runs about 10 to 16 weeks from kickoff to live in both stores. The development is rarely the bottleneck. The delays are almost always menu data, payment onboarding, and store review.
Menu data is the one that surprises people. A restaurant’s menu is not a list; it is items, modifiers, allergen information, availability windows, pricing that differs between collection and delivery, and photography that either exists or does not. Getting that into a clean structure is a genuine piece of work and it is work only you can do. Start it in week one, not week eight.
Payments need a business account, verification, and bank details in place before integration can be tested properly. If you want the detail of what that layer costs and how long it takes, our breakdown of the cost to add Stripe to a UK app covers the fee structure and the integration effort.
Store review adds days you cannot compress, and Apple and Google both reject first submissions for predictable reasons. We wrote up the common causes in our guide to preparing for app store review in the UK, and food apps have their own trap: allergen information. UK law requires accurate allergen data for food sold at a distance under the Food Information Regulations, and the Food Standards Agency has published clear guidance on what must be given to the customer before they order. Treat that as a build requirement, not a legal footnote, because it affects your data model.
The running costs nobody quotes for
The build price gets all the attention and the monthly figure gets discovered later, usually in month four. Budget for it up front, because it is predictable and it is not large.
| Item | Typical monthly cost | Notes |
|---|---|---|
| Backend hosting and database | £25 to £150 | Scales with orders, not with menu size |
| Push notification service | £0 to £40 | Free at independent restaurant volumes on most providers |
| Apple Developer Program | About £8 | Billed annually at 99 US dollars |
| Google Play Console | Negligible | One off 25 US dollar registration, no annual fee |
| Card processing | Percentage of revenue | Sits in cost of sales, not in your software budget |
| Maintenance and OS updates | £100 to £400 | The line most people forget entirely |
That last row is the one that matters. Apple and Google each ship a major operating system release every year, and an app that is not touched for eighteen months starts failing in ways that look like bugs to your customers. A retainer or a budgeted block of hours per quarter is not an upsell, it is the difference between an asset and a slowly rotting one. If nobody is maintaining it, assume a rebuild in three years and price that in.
EPOS integration: worth it, but not on day one
Every restaurant owner asks whether the app will talk to the till, and the honest answer is that it should eventually and often should not immediately. Integration with your electronic point of sale system removes double entry, keeps menu changes in one place, and stops the kitchen working from two sources of truth. Those are real benefits and they compound as you grow.
The complication is that EPOS integration cost varies enormously depending on which system you run. Some modern cloud tills have a clean, documented interface and integration is a few days of work. Older systems, and some very common ones in British restaurants, either have no public interface at all or charge for access to it, and in those cases you are looking at a middleware layer and a meaningfully bigger number. Before you assume it is included in a quote, ask the specific question: which till do you run, and has this agency integrated with it before.
Our usual advice for a first version is to run the app alongside the till with orders arriving on a tablet or a printer, live with the mild duplication for a few months, and integrate once you know the app is producing enough volume to justify the work. That sequencing has never cost a client anything except a small amount of patience, and it has saved several of them five figures on an integration they turned out not to need.
Native, hybrid, or just a good mobile site
Not every restaurant needs an app, and an agency that tells you otherwise is selling rather than advising. If your trade is largely passing custom, tourists, or one off bookings, a fast mobile ordering site will convert as well as an app and cost a fraction of the price. Apps earn their money through repeat behaviour, and repeat behaviour needs regulars.
If you do have regulars, the platform question comes next. For the vast majority of restaurant apps, a cross platform build using React Native or Flutter is the right answer, because a restaurant app does nothing that demands platform specific engineering, and you halve the cost of covering both iPhone and Android. We compared the two properly in React Native versus Flutter for UK builds if you want the reasoning. The cases for going fully native in this sector are rare and usually involve deep hardware integration in the kitchen rather than anything the customer touches.
For a broader view of where restaurant app pricing sits relative to app development generally in Britain, our UK app development cost guide for 2026 puts these numbers in context against other categories.
Six questions to answer before you brief anyone
- How many orders a week do you currently take through delivery platforms, and what is your average order value?
- What effective commission rate are you paying, including fees and VAT, not the headline number?
- What proportion of those customers are genuine regulars who would plausibly download an app?
- Do you have clean menu data with allergens, modifiers, and prices, or does that need creating?
- Who inside the business will send the push notifications and manage the loyalty scheme every week, and do they have time?
- What does success look like twelve months from now, expressed as orders per week rather than as downloads?
If you cannot answer the first three, you are not ready to commission an app, and any agency happy to quote without them is not doing you a favour. If you can answer all six and the arithmetic holds up, you are in a much stronger position than most people who start this process.
What we would tell you if you rang us today
Build the smallest thing that lets a regular reorder in two taps, pay with a saved card, collect a stamp, and receive a push notification when you want to fill a quiet Tuesday. Ship it in twelve weeks. Measure orders per week, not downloads. Then decide, with three months of real data, whether table booking and a kitchen dashboard are worth another £15,000.
That order of operations is boring and it is also why the restaurant apps that work look almost identical to each other. They are not clever. They are fast, they remember you, and they make it slightly easier to order from you than from anybody else. If you want us to run your specific numbers before you commit to anything, send us the order volumes and average order value through our project brief form and we will tell you honestly whether the payback is there, including when it is not.
.webp)
.webp)
