Food delivery is one of the few businesses you can start small, test in a single postcode, and scale street by street. It is also a business where the economics are unforgiving if you get the basics wrong. This guide walks through the decisions that actually matter: which of the three viable models to run, the setup steps to check before you trade, how the unit economics work, what software you genuinely need at launch, and how the big aggregators fit into the plan.
To start a food delivery business in the UK: pick one of three models — a local multi-restaurant platform, a single-cuisine delivery brand, or a delivery arm for an existing restaurant. Register as a food business with your local council and check current requirements on GOV.UK before you trade. Take professional advice on how you engage drivers, and talk to a broker about insurance. Keep your delivery radius tight so drivers complete more drops per hour, and launch with the smallest software stack that supports your model: an ordering channel, dispatch, and a driver view. Aggregators like Just Eat and Deliveroo are a reach channel, not a business model — most successful operators dual-run them alongside their own ordering channel.
Almost every food delivery business in the UK is a version of one of these three. They look similar from the outside — food, drivers, an app — but they are very different businesses to run. Pick deliberately, because the model decides your costs, your software and your hardest problem.
A mini-aggregator for one town or district: local restaurants list on your platform, you take the orders and run (or coordinate) the delivery.
Works when: the big aggregators under-serve your area, and you can offer restaurants a better deal than they get elsewhere.
Honestly the heaviest model: most capital, most operations, most software. Start here only if you know your patch and its restaurants well.
One focused menu, built for delivery from day one — often from a rented or shared kitchen, with no dine-in at all.
Works when: you have a genuinely strong food concept and the discipline to keep the menu short enough to travel well.
Concentrated risk: one brand, one menu. But it is the cheapest model to test, and the easiest to shut down or pivot if the numbers say no.
You already run a restaurant or takeaway — or you deliver on behalf of local restaurants that do not want to run drivers themselves.
Works when: the kitchen and the demand already exist, and delivery is incremental revenue rather than the whole bet.
The pragmatic default for most founders reading this: add your own channel, measure it against the aggregators, and expand what works.
Strip away the app and the branding, and a delivery business is a simple machine: each order must earn more than it costs to make and deliver. The delivery side of that equation is governed by three linked numbers.
Delivery radius sets how long each journey takes. Order density — how many orders come from each square mile inside that radius — sets how efficiently a driver can chain drops together. Together they determine your driver cost per drop: a driver's hour costs roughly the same whether they complete many deliveries or one, so the more drops per hour, the cheaper each one becomes.
This is why the counterintuitive advice is right: shrink the map. A tight radius means short drives, more drops per hour, hotter food and better reviews. A wide radius means long drives, expensive drops and lukewarm biryani. Depth beats breadth — it is better to be the obvious choice in three postcodes than an occasional option in fifteen.
Your margin per order — what is left after ingredients, packaging, payment fees and any commission — has to clear the driver cost per drop with room to spare for marketing and everything else. Model it honestly for the quiet Tuesday lunch, not just the heaving Friday night, because the same driver-hour maths gets much worse off-peak.
Track these weekly from your first week. Widen the radius only when the core area is consistently profitable — and be as willing to shrink it again.
At launch you need three things, and only three: an ordering channel (a fast website first — an app earns its keep once repeat customers justify it), dispatch (getting the right order to the right driver, which can be a person with a screen at tiny volume but becomes software quickly), and a driver app or driver view (the run of jobs, the route, order status and proof of delivery). Everything else — loyalty, scheduling, multi-kitchen menus — can wait until the model is proven. Build the smallest tier that supports your model.
| What you are launching | Typical build | Timeline | Price band (GBP, ex VAT) |
|---|---|---|---|
| Single-restaurant ordering site — your menu, checkout and order management | Custom storefront | 5–8 weeks | £6,000–£12,000 |
| Single-vendor delivery app (web) — ordering plus dispatch and delivery tracking for one brand | Focused delivery app | 6–9 weeks | £8,000–£14,000 |
| Multi-vendor delivery platform — multiple restaurants, commission handling, dispatch | Standard delivery platform | 9–13 weeks | £14,000–£26,000 |
| Delivery platform + driver & customer apps — the full aggregator-style stack | Full delivery product | 10–16 weeks | £20,000–£40,000 |
Prices published from our Open Price Book (v1.0 · July 2026 · next review October 2026). All prices exclude VAT.
If you are running Model 2 or Model 3, start with our takeaway ordering app page — that is the storefront and single-vendor end of the table. If you are building a multi-restaurant platform (Model 1), see delivery app development for the platform and driver-app tiers. Either way you get senior engineers on UK hours and milestone billing — you pay for delivered, accepted work.
Be honest about what the big aggregators do well, because it is a lot: they put your food in front of customers you could not reach on day one, they handle payment and (on some arrangements) the delivery logistics, and their checkout carries a trust a new brand has not earned yet. For a new operator, that reach is genuinely valuable.
Now be honest about the trade-offs. They typically charge a commission on each order, which comes straight out of the margin you just modelled so carefully. The customer relationship — the name, the ordering history, the ability to bring someone back with an offer — generally stays with the platform, not with you. And your visibility depends on a ranking you do not control.
The pragmatic answer for most operators is to dual-run. Use the aggregators as a discovery channel — that is what they are best at — while building your own ordering channel for the customers who already know you. Repeat orders through your own site or app keep more of the margin and give you your own customer data to work with. Convert regulars gently: a card in the bag, a loyalty nudge, a reason to order direct next time — within whatever your agreements with the platforms allow.
Treat the split as a number to watch, like everything else: what share of orders is direct, and is it growing? A delivery business that owns none of its demand is a tenant. Dual-running is how you stop being one without giving up the reach.
Work through this in order. Each line is covered in the sections above.
Book a free 30-minute scoping call with a senior engineer — in UK hours. We'll map your model to the smallest build that supports it, with published prices and milestone billing: you pay for delivered, accepted work.
Book a free scoping call →