Scenario · Marketplaces & consumer apps

Cost to build an app like DoorDash in 2026: a local grocery delivery MVP, part by part

What it costs to build an app like DoorDash in 2026, via a Manchester grocery-delivery MVP: the cheap parts, the expensive parts and the running costs.

By Akash Bansal, founding engineerUpdated 4 November 20268 min read

Illustrative scenario. The founder in this story is a composite, not a real client. The process, costs and decisions are drawn from builds I have done; names and business details are invented to show how a build like this typically goes.

Search "cost to build an app like DoorDash" and you get agency estimates from $15,000 to well past $160,000. One estimator puts a lean MVP at $30,000–$55,000 and a full customer, courier, merchant and admin platform at $60,000–$160,000 over six to twelve months (Project Cost Estimator). Another says a basic build takes three to four months and starts at $15,000–$30,000 (Apptunix, vendor).

The ranges are wide because they price the same list of screens without asking which parts are cheap in 2026 and which are not. This post works through that question with a composite founder in Manchester. My evidence is the at-home salon marketplace I ran technology for from 2020 to 2025, Urban Culture: four apps, 500K registered users, six cities, and a lot of time spent sending people to addresses. That is analogous to delivery, not the same. Our partners travelled to the customer; there was no pickup leg and nothing went cold. I will flag where the difference matters.

The founder and the starting point

Call him Femi. He has spent two years running WhatsApp grocery orders for five independent African and Caribbean grocers in south Manchester. Customers message a list, he relays it to the shop, the shop packs it, and Femi or one of two friends drives it over. He does 40 to 60 orders a week and charges a flat delivery fee.

He has two reasons to want an app. The WhatsApp process breaks above about 15 orders on a Saturday. And when the shops tried the big apps, they found the commission hard to live with: guides put Deliveroo and Uber Eats commission at roughly 25–35% per order (DineOpen, vendor, restaurant-focused; neither app publishes a UK grocery rate card). Shoppers notice the cost too. Which? found everyday supermarket items on Deliveroo, Just Eat and Uber Eats could cost at least 20% more than in store (Which?).

Do you need a DoorDash clone at all?

If you are one shop, probably not. An online store with local delivery plus a white-label courier service such as Uber Direct (per-delivery pricing, your own branding) gets you delivering this month for no build cost. I would tell a single-shop owner to do that and spend nothing on software.

Femi is different. He aggregates several shops into one basket, his customers want to order from two shops in one trip, and his value is the curation and the community, not the courier. That multi-shop basket is what no off-the-shelf store handles well, and it is what justifies a build.

Which parts of a delivery app are cheap now, and which aren't?

The short answer: infrastructure got cheap, judgment did not. Payments, maps and hosting cost almost nothing at a few hundred orders a week. Dispatch rules, substitutions and the edge cases around money still take real engineering time, and couriers still take real human time.

The maps line is where my Urban Culture experience is most direct. Our distance and geocoding bill grew with every booking, and we eventually replaced Google Distance Matrix and geocoding with our own geolocation service, which cut that cost 80% with accuracy held. I wrote up how we did it. At Femi's volume it would be wasted work. It is a month-18 project, not a week-2 one.

Who built it, and why

Femi had an agency quote above $70,000 for four native apps, and a freelancer quote that was cheap but vague about who would own the code and the Stripe account. He went with a founding-engineer build: one senior engineer accountable for scope, architecture, all three surfaces and launch, on a fixed quote after a scoping week. On my builds the client owns the repository and every cloud account from the first day, sees a working demo weekly, and gets design docs and a handover. Best for: a founder who already has orders and a process to encode. Not for: someone who has not delivered a single order by hand yet.

What got cut from v1

The big apps are four products glued together. Femi's v1 was three thin surfaces on one backend.

• Customer ordering as a mobile web app, not native. No store review, no $99 Apple fee, fixes ship the same day. Native comes when repeat customers ask for it.
• Courier app as a web app. A list of today's runs, a button to open the address in Google Maps, "picked up" and "delivered". No live tracking map for the customer; they get an SMS at each status change.
• No shop app. Each shop gets a picking screen on a cheap tablet: new orders, tick items, mark out-of-stock, mark packed.
• Manual dispatch. Femi assigns runs from the admin panel and batches by postcode himself. The assignment log becomes the data for automating it later.
• No live inventory sync. None of the shops' tills had an API worth using. Each shop maintains a list of about 300 regular lines in the admin panel, and out-of-stock is handled at picking time.
• Cut entirely: ratings, promo codes, wallets, scheduled orders, in-app chat, tipping.

The build, week by week

1. Week 1: scoping and the order state list. Placed, paid, picking, partially available, packed, out for delivery, delivered, refunded. Every transition, and who may trigger it, in a short design doc.
2. Week 2: catalog and multi-shop basket. One basket split into per-shop picking lists, delivery fee by postcode band rather than by live distance.
3. Week 3: payments. Card and wallet payments with an authorisation taken at checkout and the final amount captured after picking, so substitutions never need a second payment.
4. Week 4: shop picking screen. Tick, mark missing, suggest a substitute, mark packed.
5. Week 5: courier app and admin dispatch. Runs, statuses, SMS to the customer at each step.
6. Week 6: refunds, reports and a pilot with Femi's existing WhatsApp customers.
7. Week 7: fixes from the pilot and launch.

What the build and running costs look like

The build is a fixed quote after scoping. My MVP builds start at $15,000; for this scope my rough estimate is $18,000–$28,000, depending mostly on how complex the substitution and refund rules become. For a rough range on your own delivery scope, try the app cost calculator. Running costs, assuming 250 orders a week at an average basket of £45:

Read that table from the bottom. The software is a small share of what it costs to run a delivery business. The founders who get burned are usually the ones who spent $150K on software before they knew their cost per delivery.

What went wrong

• Substitutions dominated support. About one order in four had something missing in the first fortnight. The fix was a per-customer "substitute or skip" default at checkout, set once.
• Heavy items broke the courier model. A 10 kg bag of rice on a bike does not work. Orders over a weight threshold are now flagged as "car run" at checkout. This is where delivery differs most from what I built before: at Urban Culture the partner carried a known kit, not a variable basket.
• Postcode bands needed exceptions. Two streets just across a band boundary were a 25-minute drive. Femi now edits band membership per street in the admin panel.
• Authorisation holds confused customers. Seeing a pending charge higher than the final amount generated messages. A line on the confirmation screen fixed most of it.

Figures like "one in four" are the kind of number you only learn in a pilot, which is the point of running one.

What launch looked like

Femi moved his existing WhatsApp customers over first, in three neighbourhoods, with the same two drivers. The WhatsApp number stayed open for a month as a fallback. Only when Saturdays ran without him touching the admin panel for an hour did he add a sixth shop. The metric that mattered was orders delivered per driver-hour, because that number decides whether the business works at all.

Checklist if you want to build a local delivery app

1. Deliver by hand first. If you have no orders on WhatsApp, an app will not create them.
2. If you are one shop, use an online store plus a white-label courier. Build only for something the big apps and store builders can't do, like a multi-shop basket.
3. Write the order state list, including partial availability and refunds, before code.
4. Start with web apps for customers, couriers and shops. Go native on evidence.
5. Dispatch by hand and log every assignment.
6. Authorise at checkout and capture after picking.
7. Price delivery by postcode band, not by live distance, until volume makes the maths worth it.
8. Own the repo, the Stripe account and the cloud account from day one.

The home-services version of this story, with two native apps and partner payouts, is in what it costs to build an app like Urban Company, and the general rules for trimming a two-sided product are in what to cut from a marketplace MVP. If you already have orders and a process like Femi's, this is the kind of build I do; here is how I work and what it costs.