How to Build a Food Delivery App: Customer, Merchant and Driver Apps

What is a food delivery app and how does it work?

A food delivery app is a three-sided platform that takes an order from a customer, hands it to a restaurant or store to prepare, and assigns a driver to carry it to the door, while all three parties watch the same order status. The customer pays, the merchant accepts and reports when the order is ready, the server offers the job to a driver, and each status change is written once and pushed to every screen that needs it.

• A food delivery app has three client apps, customer, merchant and driver, plus an admin panel, all reading one order record on a shared backend.
• The merchant app decides whether food is hot at the door: menu availability, preparation time and the ready event drive pickup timing and the customer’s delivery time estimate.
• Order batching lowers cost per delivery but adds detours, and research in Transportation Science treats the unknown time at which food is ready as one of the two main sources of uncertainty in dispatch.
• Uber Eats charges restaurants 20% to 30% of the order value for delivery, and McKinsey estimated the average platform contribution margin at around 3 percent, roughly $1.20 per order.
• Typical-scope planning estimates run from $40k to $80k for a single-restaurant ordering MVP to $150k to $350k+ for a multi-restaurant platform with three apps.

The first decision is where the order lives. On the multi-country food and grocery delivery platform Sigi built for an undisclosed client, an order is one state machine on a Node.js backend, and the Flutter customer, merchant and driver apps subscribe to it rather than keeping their own copies. The lifecycle runs: order created, merchant accepts and sets a preparation time, the order enters a Redis dispatch pool on acceptance and is offered to a nearby driver, merchant marks the order ready, picked up, delivered, then commissions and loyalty credits post on completion. Before that build, a merchant marking an order ready did not release it to a driver, so customers phoned to ask where their food was.

Courier dispatch, the driver app and live tracking are covered in Sigi’s guide to how to build a delivery app. This guide stays on the merchant side, because that is where a food delivery app differs from a parcel app.

What features does a food delivery app need?

Food delivery app features split by user. These lists are drawn from what shipped on the food and grocery delivery platform and on Kwik eMart, a 15-minute grocery delivery app Sigi built for Glenshire Group in Scotland.

Customer app

• Browse restaurants and stores by location, with menus and catalogs managed by the merchants themselves.
• Real-time availability, so a sold-out dish or grocery line never reaches the basket.
• Basket, coupons and checkout by card or wallet, with the delivery fee shown before payment and a choice of delivery or collection.
• Live tracking from acceptance to the door, then order history, one-tap reorder, loyalty credits and a referral code.

Merchant app

• Menu and product management: items, prices, availability and preparation times, changed without contacting support.
• New-order alerts with accept and reject actions, where a rejection carries a reason that triggers a policy refund.
• Ticket printing to the Bluetooth or Wi-Fi receipt printers already on the counter, so nobody retypes an order.
• Opening hours and slot control to throttle orders during a rush, promotions with start and end dates, and an earnings view with the next payout.

Driver app and admin panel

• Driver: automated assignments from the dispatch pool, an in-app route to the merchant and then the customer, photo or signature proof of delivery, and earnings.
• Admin: merchant onboarding, approval and suspension, commission rates per merchant or market, delivery zones with per-zone fees and surge pricing, policy-driven refunds, and audit logs on price, fee and status changes.

How do menus, inventory and preparation times stay accurate?

Three things go wrong most often: the menu shows a dish the kitchen has stopped serving, the store sells a line the shelf does not have, and the preparation time is a guess that leaves a driver waiting at the pass. Menus belong to the merchant. On the food and grocery delivery platform, merchants manage their own menus, availability and preparation times from the merchant app; if every change went through a support ticket, the menu would be wrong more often than right.

Preparation time is the merchant’s estimate of how long an order takes from acceptance to ready for pickup, and it is the one input that links the kitchen to dispatch. On the food and grocery delivery platform the merchant sets a preparation time on acceptance and later marks the order ready, and it is that acceptance which releases the order into the Redis dispatch pool, so a driver is already moving while the kitchen works. On Kwik eMart, reaching the packed state in the pick-and-pack queue triggers driver assignment. Dispatch fires on a real merchant event, not on a timer.

How does a food delivery app estimate delivery time and batch orders?

A delivery time estimate has two parts: how long the merchant needs, and how long the trip takes. The trip half is a maps problem. Google’s Routes API computes a route taking live traffic conditions into consideration under the TRAFFIC_AWARE preference, and its Compute Route Matrix returns distance and duration for every origin and destination pair in one request, up to 625 elements for non-transit routes. The merchant half is harder, because a kitchen’s ready time is a forecast.

Order batching is the practice of assigning one driver two or more orders that share a pickup or drop-off area, so the platform pays for one trip instead of two. It is why the economics of a multi-restaurant delivery platform improve with density, and why customers see detours. The academic form is the Meal Delivery Routing Problem, introduced by Reyes, Erera, Savelsbergh and colleagues in 2018, with multiple restaurants as pickup points and orders arriving through the day. Ulmer, Thomas, Campbell and Woyak added unknown food ready times as a second source of uncertainty and showed that postponing some assignments, with a time buffer against late kitchens, reduces missed deadlines. A study of on-demand delivery from stores reported a dynamic dispatching policy beating the operator’s existing policy by 36.53% on average in delivery time. For a founder: batching is worth building, and it depends on the ready-time signal from the merchant app.

On the food and grocery delivery platform, assignment stays on the server: the order enters a dispatch pool in Redis and is offered to a nearby, available driver, and an unanswered offer rolls to the next driver. The apps render the assignment the backend made, so the offer radius, timeout and any batching rule can change without an app store release.

How do commissions and payouts work in a multi-restaurant delivery platform?

A multi-restaurant delivery platform is a marketplace in which the operator collects the customer’s payment, keeps a commission, and pays the merchant and the driver their shares. The market sets expectations for the restaurant commission. Uber Eats publishes marketplace fees of 20%, 25% and 30% for delivery on its Lite, Plus and Premium plans, and 7% on pickup orders. Kwik eMart’s public partner offer is a 10% commission per delivered order with weekly bank payouts. Whatever you set, keep McKinsey’s number in view: platforms averaged a contribution margin of around 3 percent, or roughly $1.20 on the average order, in a market sized at more than $150 billion that had more than tripled since 2017.

The payments mechanism is well documented. Stripe’s separate charges and transfers charge type takes one payment on the platform account and transfers funds to multiple connected accounts; Stripe’s own example is “a restaurant delivery platform that splits payments between the restaurant and the deliverer.” The platform’s balance is debited for Stripe fees, refunds and chargebacks, a transfer_group ties the charge and its transfers to one order, a transfer should name the charge as its source_transaction so it waits for the funds, and outside a supported cross-border set, platform and connected accounts must be in the same region.

On the food and grocery delivery platform, commissions and service fees are computed on completion from rates set per merchant or market, and refunds follow policy rather than negotiation. Checkout never talks to a gateway directly: the app asks the backend for a payment session, a routing layer picks Adyen for Switzerland, where TWINT is expected, or Stripe or PayPal elsewhere, and every provider writes back to one payment record with the same statuses. Finance reviews one ledger, not three dashboards.

How do group ordering and loyalty fit into the order flow?

Group ordering is a shared basket in which several people add their own items to one order from one merchant, and the platform handles who pays for what. It is easy to build badly: a shared basket with no cutoff will stall a kitchen. On the food and grocery delivery platform it was the feature the client cared most about, and Sigi shipped it with firm rules.

• Host: whoever starts the group order chooses the merchant, address and time slot, and is the only participant who can submit.
• Joining: guests join through a shared link and add their own items, each tagged with the guest’s name for the merchant’s ticket.
• Split: the host pays for everyone or each participant authorizes their own share, and the order only submits once every share is authorized.
• Cutoff: when the host’s deadline passes, the basket locks, unpaid shares are dropped or picked up by the host, and the order goes to the merchant.
• Credits: loyalty credits and discount codes apply per participant to their own share, never to someone else’s.

Loyalty works when it is a line in the same ledger as everything else. On that platform, credits post on completion, referral codes reward both parties, and because all three gateways write to one payment record, credits behave identically whichever gateway moved the money. Kwik eMart takes the simpler route for a repeat grocery shop: order history and one-tap reorder.

What tech stack should you use for a food delivery app?

Food delivery app development needs five parts: a cross-platform mobile framework, a backend that owns the order state machine, a database plus a fast store for state that changes every few seconds, a push channel, and services for payments and maps. Sigi has shipped two stacks that meet those needs.

• Mobile: Flutter on the food and grocery delivery platform, where the three apps share one codebase and the same networking, authentication and order models; React Native on Kwik eMart. See Flutter versus React Native for when Sigi picks each.
• Backend: Node.js on AWS for the food and grocery platform, owning orders, dispatch, payment routing and ledgers. Kwik eMart runs a Laravel backend on a single Linux VPS.
• Data: MySQL as the system of record for orders, menus, merchants, drivers and ledgers, with Redis in front for driver locations, open dispatch jobs and group-order basket sessions.
• Push: Firebase Cloud Messaging so each app hears a state change the moment it happens; Kwik eMart adds SMS and email.
• Money and maps: Stripe, with Adyen and PayPal where a market needs them, and Google Maps for routing and ETAs. Kwik eMart falls back to OpenStreetMap for the partner map pin so a new store is never blocked on a paid maps key.

How much does it cost to build a food delivery app?

Food delivery app cost follows the number of surfaces, markets and payment rails, and how much merchant-side logic must be production-grade at launch. Sigi does not publish client invoices and does not attach a figure to any named build. The ranges below are typical-scope planning estimates for a professional custom team, consistent with the bands in Sigi’s guide to how much it costs to build a mobile app.

On timeline, guides ranking for how to build a food delivery app commonly cite three to four months for a minimum viable product and six to nine months for all four surfaces. Treat those as market figures, not a Sigi commitment. What Sigi can state is the order of work on the food and grocery delivery platform: the state machine and payment routing first, then the customer, merchant and driver apps in turn, each tested against real transitions rather than mocks.

Should you build a custom food delivery app or buy an Uber Eats clone?

An Uber Eats clone is a pre-built script with a customer app, restaurant app, driver app and admin panel that you rebrand. Vendors sell them for a few thousand dollars and promise a launch in days. That is the right purchase when you are testing whether a town will order from your restaurants at all, the vendor’s commission and dispatch rules match yours, and you accept that the vendor’s data model and roadmap are now yours.

Custom food delivery app development is the right answer when the rules are the business. If you need substitution preferences at the shelf, a ready event that gates dispatch, a batching rule you can tune, commissions that differ by market, group ordering with a cutoff, or payouts that wait for a check to clear, a clone will fight you on each. Sigi recommends the off-the-shelf route where it fits; a business selling a simple catalog should use a hosted store. Busy Bean, Kwik eMart and the food and grocery platform were custom builds because their operators needed to own those rules.

How to build a food delivery app step by step

Here is the build sequence Sigi follows. Each step fixes decisions the next depends on.

1. Write the journeys for customer, merchant, driver and operator, including the unhappy paths: a rejected order, an empty shelf, a driver who does not answer.
2. Define the order state machine: every state and the event that moves an order between them. Dispatch, notifications and payouts hang off it.
3. Decide the money model: commission, delivery fee per zone, service fee, refund policy and gateway per market. Put every calculation on the server.
4. Design the merchant app first. Menu ownership, availability, preparation time and the ready event make the rest of the platform work.
5. Agree an API contract for orders and status, then build the backend and the apps on parallel tracks against it.
6. Build the customer app, then the driver app, then an admin panel that is internal and correct rather than a second consumer product.
7. Wire payments, maps, push and receipt printers. Test each gateway in its sandbox before a market goes live.
8. Add group ordering, loyalty and referrals inside the same order flow, then take the apps through both store reviews.

Related reading

For courier dispatch, the driver app and live tracking, read how to build a delivery app. The marketplace pattern behind every multi-restaurant platform is covered in how to build a multi-vendor marketplace. For the cost bands used above, see how much it costs to build a mobile app, and for the framework decision, Flutter versus React Native. The builds cited here are the food and grocery delivery platform case study, the Kwik eMart grocery delivery platform case study and the Busy Bean Coffee ordering platform case study. If you are planning a restaurant, grocery or multi-merchant product, see Sigi’s food delivery app development practice and on-demand app work, or contact Sigi with your merchant count, markets and target delivery time.