The short answer
Building a food delivery platform like Deliveroo costs £45,000 to £150,000 depending on scope. A V1 with customer ordering, restaurant portal, and basic dispatch takes 12-14 weeks and costs £45,000-£65,000. Adding a rider app with real-time tracking brings the total to £75,000-£110,000 in 18-22 weeks. RaftLabs delivers food delivery platforms on fixed-price contracts, typically in 12-14 week build cycles.
Key Takeaways
Jake runs four restaurant brands out of a ghost kitchen in Manchester. Fried chicken. Smash burgers. A Thai wrap concept. A vegan brunch menu. All four brands live on Deliveroo, Uber Eats, and Just Eat. On a good week, the kitchen does 1,800 orders. On a typical week, Deliveroo takes roughly £3.50 on every £12 order after commission. That's 30% gone before Jake pays rent, staff, or ingredients. He is not alone: over 70% of UK online food delivery orders go through third-party aggregators, and commission rates of 25-35% are standard across all three major platforms.
He has tried to build a loyalty program. The platforms don't let him access customer emails. He wanted to offer a Friday subscription box. No mechanism for that either. His best brand -- the smash burger -- has a repeat customer rate he can only estimate based on volume trends, not actual data.
The question isn't whether Jake should leave Deliveroo. It's whether a custom food delivery platform makes financial sense at his volume, what it actually costs, and what he gets that Deliveroo never gives him.
Building a food delivery platform like Deliveroo costs £45,000 to £150,000 ($57,000 to $190,000 USD) depending on scope. A V1 with customer ordering, a restaurant portal, and basic dispatch takes 12-14 weeks and comes in at £45,000-£65,000. The full build with a rider app, real-time tracking, surge pricing, and a subscription tier takes 24-30 weeks at £110,000-£150,000.
| Build option | What's included | Cost range | Timeline |
|---|---|---|---|
| V1: Restaurant ordering + basic dispatch | Customer app, restaurant portal, admin dashboard, basic zone dispatch | £45,000-£65,000 | 12-14 weeks |
| V2: V1 + rider app + real-time tracking | V1 plus native rider app, WebSocket tracking, push notifications | £75,000-£110,000 total | 18-22 weeks |
| V3: Full platform | V2 plus surge pricing, advanced analytics, subscription delivery pass | £110,000-£150,000 total | 24-30 weeks |
| White-label (HungerRush, Olo, Bopple) | Branded ordering, no rider dispatch, monthly SaaS fee | £15,000-£40,000 setup + ongoing fees | 4-8 weeks |
| Shopify + ordering apps | Basic ordering, no dispatch, breaks at rider management | £3,000-£8,000 | 2-4 weeks |
| Clone scripts | Demo looks complete; breaks at multi-party payments and dispatch | £500-£5,000 upfront | Days to weeks |
Clone scripts deserve more than one line. They consistently fail at two points: multi-party payment splits and dispatch logic. Stripe Connect for a three-way split (customer to platform, platform to restaurant, platform to rider) is not a copy-paste integration. Clone scripts handle it with workarounds that stop working the moment you have a refund, a contested order, or a VAT rounding edge case. The dispatch logic is usually hardcoded for a single city zone with no radius scaling. When you try to extend it, you're modifying someone else's undocumented code.
Most operators who commission a food delivery platform are not trying to replace Deliveroo nationally. They're solving a specific operational problem at a specific volume.
When you run multiple brands from one kitchen, you're paying commission on every brand independently. You also have no way to cross-promote brands to the same customer. A custom platform lets you consolidate the customer relationship, offer bundle promotions, and cut commission dependency on your highest-volume brands. At 1,500+ orders per week, the maths usually works within 18-24 months.
Corporate catering delivery, office lunch programmes, and healthcare meal delivery don't need a consumer-facing marketplace. They need reliable bulk ordering, fixed delivery windows, invoice billing, and dietary filter management. Deliveroo's consumer model creates friction in every one of those workflows. A custom platform designed for B2B accounts -- with fixed pricing, recurring order scheduling, and per-account admin access -- is a fundamentally different product.
The Gopuff model applied to a single UK city or region: stock a dark store with high-velocity grocery and convenience items, promise 15-30 minute delivery, own the dispatch. Deliveroo's quick commerce partnerships exist but give the operator zero control over delivery windows or customer experience. A custom platform is the only way to own the full stack.
Deliveroo's per-location commission becomes a material cost line at this size. A restaurant group with 10 sites doing an average of 200 orders per week each -- at 30% commission on a £14 average order -- is paying roughly £8,400/week in commission. A custom platform doesn't eliminate delivery cost, but it replaces a percentage-of-revenue fee with a fixed operational cost that gets cheaper per order as volume grows.
A food delivery platform is three apps and one admin system that have to talk to each other in near real time.
Customer app. Menu browsing with category filters, real-time item availability, cart with customisation options, checkout with saved addresses, live order tracking (map + status updates), past order reordering, review submission. The tracking screen is the most technically demanding part of the customer app -- it requires a persistent WebSocket connection that survives mobile sleep states, which most clone scripts don't handle correctly.
Restaurant portal. Menu management (items, categories, modifiers, photos, pricing), live order board (new orders, prep status, ready for pickup), order history, earnings dashboard, payout schedule, analytics by item and time period. The restaurant portal often gets underscoped. Operators want menu management that a non-technical staff member can use on a busy Friday night. That means clear UI, forgiving validation, and offline-tolerant design.
Rider app. Job notification with accept/reject, order pickup confirmation, map navigation (Google Maps or Mapbox integration), delivery confirmation with photo capture, shift management, earnings dashboard, payout history. The rider app is a real-time tool used by people on bikes and mopeds in variable conditions. It needs to be fast, simple, and functional on mid-range Android devices (not just the latest iPhone).
Dispatch algorithm. Zone-based rider pool management, order assignment by proximity and estimated travel time, rider acceptance rate tracking, re-dispatch on rejection, surge pricing input (rider count vs. incoming order volume). This is the component that makes or breaks delivery SLAs. Google Maps API gives you routing times. The assignment logic -- who gets which order, in what order, with what fallback -- has to be built from scratch.
Admin dashboard. Restaurant onboarding and approval, commission rate configuration per restaurant, order oversight and manual reassignment, promotions and discount code management, fraud detection flags, payout processing, platform-wide analytics. The admin panel is often the last thing scoped and the first thing the operations team resents not having enough of.
Payment infrastructure. Stripe Connect for multi-party splits: customer pays platform, platform distributes to restaurant and rider after taking its commission. This includes VAT handling on commission (restaurant pays VAT on the commission, not the full order value), refund routing (who absorbs the cost of a rejected order), and payout scheduling. The payment module accounts for 25-30% of total V1 development effort -- budget for it correctly.
Weeks 1-2: Schema design, Stripe Connect setup, zone mapping. The database schema -- orders, restaurants, riders, zones, payments -- determines everything downstream. Stripe Connect onboarding for restaurants takes longer than most people expect: identity verification, bank account linking, terms acceptance. Zone maps define the dispatch radius and are the foundation of the surge pricing model later.
Weeks 3-6: Customer app + restaurant portal. Menu browsing, cart, checkout on the customer side. Menu management and live order board on the restaurant side. By week 6, a restaurant can receive and confirm an order.
Weeks 7-10: Rider app + basic dispatch. Job notification, accept/reject, navigation, delivery confirmation. Basic dispatch: nearest available rider in zone. By week 10, end-to-end order flow from customer to rider works.
Weeks 11-14: Admin dashboard + tracking + payment reconciliation. Order tracking with WebSockets. Admin panel with restaurant management and commission controls. Payment reconciliation including refund logic and payout scheduling. By week 14, the V1 platform is production-ready.
Weeks 15-22 (V2): Surge pricing, push notifications, native mobile apps. Surge pricing engine based on rider-to-order ratio by zone. Proper push notifications (not just in-app). Native iOS and Android apps replacing the PWA from V1 (better performance for the tracking screen).
Weeks 23-30 (V3): Subscription delivery pass, advanced promotions, white-label support. Subscription tier (£6.99/month for free delivery, paid monthly via Stripe Subscriptions). Advanced promotion types: discount codes, bundle deals, first-order offers. White-label mode for restaurant groups who want to operate the platform under their own brand.
UK food delivery platforms must address rider worker classification (post the 2021 Uber v Aslam ruling), GDPR data handling, FSA hygiene rating integration, and alcohol age verification under the Licensing Act 2003. Getting any of these wrong creates legal liability before your first order is delivered.
Gig worker classification. The 2021 UK Supreme Court ruling in Uber v Aslam established that Uber drivers were "workers" rather than independent contractors. Workers are entitled to the national minimum wage, holiday pay, and auto-enrolment pension contributions. The platform design matters here: the more control mechanisms you build in (mandatory acceptance rates, fixed shift structures, performance-based deactivation), the stronger the case that riders are workers rather than genuinely self-employed contractors. A UK employment solicitor should review your rider contract and platform mechanics before you onboard the first driver.
GDPR. Customer order history, delivery addresses, and payment methods are personal data under GDPR. You need a lawful basis for processing, a privacy policy that covers your data processor relationships with restaurants and riders, and a right to erasure mechanism. When a customer requests deletion, you need to be able to delete or anonymise their data while retaining the order records you need for VAT compliance. These two requirements pull in opposite directions -- design the data model to accommodate both before you build.
Food Standards Agency hygiene ratings. UK consumers expect to see FSA food hygiene ratings on food platforms. Deliveroo, Uber Eats, and Just Eat all display them. The FSA provides a public API for ratings data. Building the integration is straightforward; the harder part is the operational process for what happens when a restaurant's rating drops below your minimum threshold.
Alcohol delivery and age verification. Under the UK Licensing Act 2003, alcohol can only be sold to people aged 18 or over. If any restaurant on your platform sells alcohol, you need an age verification mechanism at checkout. The most practical approach is a challenge-25 prompt on the delivery confirmation screen, with a rider protocol for requesting ID. This needs to be in your terms of service and trained into your rider onboarding.
FCA considerations. If you build a cashback feature, a stored credit product, or a subscription model with deferred payment, you may trigger Financial Conduct Authority regulated activity. A standard subscription delivery pass (flat monthly fee for unlimited deliveries) is generally fine. Stored customer credits and reward points that can be redeemed for cash equivalents are more complicated. Take legal advice before building any feature that involves holding customer funds.
Digital Services Act. If you expand to EU markets post-Brexit, the DSA applies to platforms above certain user thresholds. For a single-market UK platform, this is a future consideration rather than a day-one requirement.
The four problems that consistently surprise food delivery teams are: real-time dispatch logic under concurrent load, WebSocket reliability on mobile, Stripe Connect multi-party refund handling, and live menu sync during active service. Each one adds 2-6 weeks to the build if not planned for upfront.
Real-time dispatch under load. The failure mode we see most often in food delivery builds is treating the dispatch algorithm as a simple database query: "find the nearest rider, assign the order." That works for the first 50 orders. It breaks when you have 200 simultaneous orders across a city, riders in flux between zones, and a surge in one postcode making the nearest-rider assignment suboptimal. The teams that think through zone balancing and re-dispatch logic before writing the first line of code save 6-8 weeks of rework post-launch.
WebSocket reliability on mobile. Real-time order tracking requires a persistent connection between the customer's phone and your server. Mobile operating systems aggressively kill background connections to preserve battery. Your WebSocket implementation needs reconnection logic that re-establishes the connection within 2-3 seconds of a drop, with a visual indicator so the customer knows the tracker is live. This is not the default behaviour of most WebSocket libraries out of the box.
Multi-party payment splits. Stripe Connect is a marketplace payment product, not a simple payment gateway. The split between your platform commission, the restaurant's share, and the rider's per-delivery payment happens at the Stripe level, not at the application level. This matters for refunds: if a customer disputes an order, who absorbs the cost? Your refund policy and your Stripe Connect configuration need to agree. VAT on commission payments adds another layer: in most structures, restaurants pay VAT on the commission they pay to the platform, not on the full order value. Get this wrong and you create a tax liability for your restaurant partners.
Menu sync mid-service. Restaurants update menus during service. A customer browses the menu at 7:45pm. The restaurant marks a dish as unavailable at 7:47pm. The customer adds it to cart. What happens? The correct behaviour -- real-time availability updates with graceful cart handling -- requires careful state management on the client side and an event-driven update mechanism on the server side. The lazy implementation (no real-time sync, batch update every 5 minutes) causes 2-3% of orders to include unavailable items. At 1,000 orders a day, that 2-3% is a constant stream of complaints and refund disputes.
Surge pricing feedback loops. Surge pricing is more complex than a multiplier on base delivery fees. It needs to reflect actual rider supply versus order demand, respond to rider acceptance rates (if riders are declining orders, pricing needs to rise to attract more riders to the zone), and avoid pricing swings so aggressive they drive customers away. The surge model needs tuning data from real operational weeks -- you won't get the parameters right in a simulator.
"The platforms that survive and thrive are the ones that treat the dispatch algorithm as a product, not a feature. The moment they commoditize it is the moment a competitor with better routing takes their riders." -- Stuart Eames, CEO, Stuart (B2B last-mile logistics platform, operating across France, UK, Spain, and Poland)
According to Statista's UK food delivery market data, the UK online food delivery market reached approximately £14.3 billion in 2025, with the market expanding 87% since 2019. The growth is concentrated in specialised segments: quick commerce, B2B catering delivery, and subscription food services -- all areas where the large aggregator platforms have deliberately not invested, because their commission model doesn't work as well at those use cases.
High commission fees charged by aggregators, which range from 25-35% of order value, have prompted 40% of independent restaurants in the UK to launch or upgrade their direct ordering systems in 2024 to capture higher margins and retain customer data. Among operators with multiple sites, the economics of switching accelerate: the fixed operational cost of a custom platform falls on a per-order basis as volume grows, while platform commissions do not.
V1 proves one thing: that customers on your platform will order from your restaurants. Everything else is secondary.
What V1 includes: customer app (menu browsing, cart, checkout, basic tracking via status updates not map), restaurant portal (menu management, order acceptance, prep status), basic dispatch algorithm (nearest available rider by zone), admin dashboard (restaurant and rider management, commission config), Stripe Connect payments with three-way split.
What V1 does not include: native mobile apps (V1 runs as a PWA), real-time map tracking, push notifications (email only), surge pricing, analytics dashboard, or subscription products.
The business milestone V1 unlocks: your first independent order, processed without Deliveroo taking commission. V1 is also the proof-of-concept you need to show investors or franchise partners that the platform works.
V2 is the operational upgrade that makes the platform competitive with the major aggregators on customer experience.
What V2 adds: native iOS and Android apps for customers and riders (better performance for the tracking screen), real-time map tracking via WebSockets, push notifications for order status updates, surge pricing engine (zone-based supply/demand multiplier), rider earnings dashboard with payout transparency.
The business milestone V2 unlocks: the ability to acquire customers who expect the same real-time tracking experience they get on Deliveroo. Without map tracking, customer satisfaction scores for delivery apps typically run 20-25% lower than with it.
V3 adds the features that differentiate you from a Deliveroo clone and create the revenue streams Deliveroo won't build for you.
What V3 adds: subscription delivery pass (£6.99/month, free delivery on all orders), advanced analytics (restaurant performance, customer lifetime value, cohort retention), promotional engine (discount codes, bundle deals, first-order offers), white-label mode (restaurant groups can run the platform under their own brand), and B2B corporate accounts (fixed monthly fee per client, consolidated invoicing).
The business milestone V3 unlocks: recurring revenue from subscription customers (which Deliveroo can't replicate for your specific restaurant portfolio) and the ability to price differently for B2B clients who need delivery SLAs that consumer platforms don't offer.
Competing with Deliveroo on its own terms -- broad consumer marketplace, national brand, aggressive marketing -- is not a viable strategy for a new entrant with a development budget.
Competing in the areas where Deliveroo has structural weaknesses is a different question.
Deliveroo for Work exists but is a minor product for them. Corporate catering contracts, office lunch programmes, and healthcare facility meal delivery are markets where the buyer is a facilities manager or HR team, not a consumer. They need consolidated invoicing, dietary management, delivery window guarantees, and per-department spend reporting. A platform designed for that workflow will beat Deliveroo's consumer product every time.
Deliveroo Plus (their subscription product) is a flat delivery pass with no restaurant-specific loyalty features. A custom platform can build restaurant-branded loyalty: stamps, tiered rewards, subscription boxes for specific cuisine types. None of these are possible when you're a restaurant listed on Deliveroo's marketplace.
Deliveroo focuses quick commerce investment on high-density urban areas. A dark store operator in a mid-size UK city -- Leicester, Stoke, Exeter -- with a 15-minute delivery promise has limited competition in that geography. A custom platform designed around that specific zone is a more efficient operation than a national aggregator trying to retrofit its logistics model.
On Deliveroo, the platform owns the customer relationship. A custom platform gives you the customer's email address, order history, dietary preferences, and lifetime value. That data is the foundation of any retention strategy, loyalty programme, or re-engagement campaign. It's also required if you want to run targeted promotions or build a subscription product.
Adjacent products worth knowing: Stuart handles B2B last-mile dispatch. Bopple builds white-label ordering for restaurants -- ordering without dispatch. Slerp focuses on direct-to-consumer restaurant ordering. None of them offer the full stack -- dispatch, ordering, and customer data ownership -- that a custom build gives you.
A food delivery platform has more revenue levers than Deliveroo lets you see from the restaurant side.
Your platform charges restaurants 10-25% commission -- significantly below Deliveroo's 30-35%. That gap is your acquisition hook. A restaurant doing 400 orders per week at a £14 average order value saves approximately £700-£1,400 per week by switching from Deliveroo to your 15% commission platform. The savings fund the restaurant's switching cost within weeks.
A £6.99/month pass for free or discounted delivery on all orders. At 500 subscribers, that's £3,500/month in recurring revenue with near-zero marginal cost. Subscription customers also order more frequently -- Deliveroo's own data (disclosed in their 2022 IPO prospectus) showed that Plus subscribers ordered approximately 2.4x more frequently than non-subscribers.
Restaurants can pay for priority positioning in search results and category lists. This is a significant revenue line for the major platforms. At 30+ restaurants on the platform, it becomes a meaningful additional income stream.
A fixed monthly fee per corporate client for managed delivery accounts. Corporate clients typically sign 6-12 month contracts, providing more predictable revenue than transaction-based commission.
At 500 orders per day at an average order value of £12 and a 15% commission rate, your platform generates approximately £900/day in commission revenue -- roughly £27,000/month. At that volume, the operational cost of running the platform (infrastructure, support, payment processing fees) typically runs £3,000-£5,000/month, leaving substantial contribution margin before rider costs. That threshold is achievable in 12-18 months for an operator starting with an established restaurant portfolio.
Keep using Deliveroo for single-location restaurants under 200 orders per week. Use white-label ordering (Bopple, Slerp) when you want branded ordering without a rider fleet. Build custom when you run 3+ brands, own your delivery fleet, or have a subscription product in your roadmap -- the payback period at 400+ weekly orders is typically under 12 months.
Keep using Deliveroo when you have fewer than 200 orders per week across all your locations, run a single-site restaurant with no expansion plans, and have no loyalty programme, subscription product, or corporate catering ambitions. At that volume, the 30% commission is painful but not existential.
Use white-label ordering (Olo, Bopple, Slerp) when you want your restaurant's branding on the ordering experience but don't need your own rider fleet. You'd rather use Stuart or your existing Deliveroo/Uber Eats delivery integration, and you want direct customer data without building the ordering engine from scratch. Bopple and Slerp are the most relevant UK options; setup costs £15,000-£40,000 plus monthly SaaS fees.
Build custom when you run 3+ restaurant brands and want to cross-promote between them. When you operate or plan to operate your own rider fleet. When you have a subscription product, corporate catering service, or quick commerce operation in your roadmap. When you're doing 400+ orders per week and the commission cost has become a material business problem. When you want the customer data to build retention and loyalty programmes that Deliveroo will never hand over.
The payback calculation is straightforward. A ghost kitchen doing 1,500 orders per week at £12 average order value pays approximately £54,000/month to Deliveroo at 30% commission. A custom platform at 15% commission costs £27,000/month in commission equivalent, plus £3,000-£5,000/month operational overhead. The saving of £22,000-£24,000/month pays back a £100,000 platform build in under 5 months at that volume.
We've built on-demand platforms and multi-sided marketplaces across hospitality, logistics, and retail. The pattern in food delivery specifically -- multi-party Stripe Connect, real-time dispatch, restaurant portal UX -- repeats across verticals. We've seen the places where delivery platforms fail at the build level (dispatch logic that works in staging but breaks under concurrent load) and at the product level (rider apps that don't account for poor connectivity in dense urban areas).
Our engagements work on fixed-price contracts with fortnightly working software milestones. The scope is agreed before a line of code is written. The number in the proposal is the number you pay. For a V1 food delivery platform, that typically means 12-14 weeks from kickoff to a production-ready system your restaurant partners can migrate to.
If you're a ghost kitchen operator, restaurant group, or B2B delivery company evaluating the build case, the first step is a scoping conversation where we review your current operational data -- order volume, average order value, number of restaurant brands -- and give you a fixed-price proposal within 2 business days. No retainer, no extended discovery phase. If the numbers don't support a build at your current volume, we'll say so.
Ask an AI
Get an instant summary of this post from your preferred AI assistant.
Stay on topic
We will scope the build, give you a fixed price, and deliver in 12-14 weeks. No retainer, no surprises.
Related articles
A multi-sport complex paying $45K/year to LeagueApps wants out. Here is what it costs to build your own league management platform ($50K-$190K), what COPPA compliance adds to the scope, and when the math tips toward a custom build.
A regional youth soccer club with 40 teams pays $9,600/year in TeamSnap team subscriptions -- with no white-label branding, no registration fee control, and player data locked in TeamSnap's system. Here is what it costs to build your own team sports management app ($60,000--$230,000), what COPPA compliance requires for youth player data, and when building makes sense for leagues and national federations.
A 10-location restaurant group pays $133,500/year to Toast in SaaS fees and transaction cuts. Here is what it costs to build your own restaurant POS ($80,000–$220,000), what PCI DSS compliance adds to the scope, and when owning your stack makes financial sense.
