Case study · On-demand & food delivery
Three apps, one order, and food that is still hot
A delivery marketplace is not one product. It is a customer app, a restaurant terminal and a courier app that must agree about the same order, minute by minute, while the food gets cold.
Engagement · Product development
Three apps over one order state machine.
- Industry
- On-demand & food delivery
- Solution
- Three-sided delivery marketplace
- Engagement model
- Product team
- Market stage
- Launch by area
- Client
- A delivery service, UAE
- Scope
- Product development
- Platform
- iOS · Android · Tablet · Web
- Constraint
- Every minute visible to the customer
Outcomes
The figures a delivery platform lives or dies on
Three sides, one order, and a customer watching a map the whole time.
-
28%
Faster average delivery time
Dispatch weighted by preparation time and direction of travel, rather than picking the nearest courier to the restaurant and hoping.
Measured from order placed to delivered
-
45%
Fewer cancelled orders
Kitchens pause when they are underwater instead of accepting food they cannot cook in time, so the platform stops making promises it will break.
Measured across orders after kitchen pause control shipped
-
60%
Increase in repeat orders
A customer whose food arrived when the app said it would orders again. Honest estimates are a retention feature.
Measured across returning customers by area
Context
The situation before the platform
Why a delivery marketplace is three products rather than one.
The business
A multi-restaurant delivery service connecting customers, kitchens and couriers in a dense urban market.
The starting point
Delivery is the least forgiving software there is. The customer watches a map, the kitchen is mid-service, the courier is on a bike, and the food is getting cold throughout.
The trigger
A platform thirty seconds out of date is visibly wrong. Unlike most software, the customer can see the discrepancy between what the app claims and what is happening.
What they wanted
Three apps agreeing about one order, dispatch that is sensible when several orders are ready at once, and honesty with the customer when something slips.
Constraints
Three sides, each able to break the other two · restaurants go busy or close without warning · courier supply and demand rarely match at peak · the estimate given at checkout sets the expectation permanently.
System
What it runs at today
The platform as delivered across the three sides.
-
4
Order states the customer sees
Accepted, preparing, collected, delivered — each meaning something real
-
1
Tap to accept or reject
What a kitchen terminal can demand of someone mid-rush
-
3
Dispatch inputs
Preparation time, courier position and direction of travel
-
0
Optimistic estimates
Promised conservatively and updated when reality changes
The engineering problem
Four problems in a three-sided marketplace
Each side can break the other two. These four decided how the platform was built.
-
The kitchen is the constraint, and it is the least willing user
A marketplace with a beautiful customer app and a terminal no chef will touch has no supply. A kitchen mid-service has one hand free and three seconds of attention.
What we did
We spent time in kitchens during service, then built the terminal to demand exactly one tap to accept or reject, with a pause control for when the kitchen is underwater.
-
Three clients will each hold their own idea of the order
Customer, kitchen and courier apps updating independently produce three versions of one delivery. The customer sees "preparing" while the courier is already outside, and nobody can tell which is right.
What we did
One order state machine on the server, with all three apps as views onto it. No client is permitted its own interpretation of where an order has got to.
-
Nearest courier is the wrong answer
Assigning the closest courier to the restaurant ignores preparation time and direction of travel. It produces couriers waiting at counters and deliveries that double back across a city.
What we did
Dispatch weighted by how long the food actually needs, where the courier is heading, and what else is ready — rather than straight-line distance to the kitchen.
-
The estimate at checkout sets expectations permanently
An optimistic delivery time is a promise the platform will break in front of the customer. Once broken, no amount of accuracy afterwards repairs the impression.
What we did
Conservative estimates at checkout, updated honestly when reality changes, on the principle that arriving early is forgivable and arriving late is not.
Architecture
How it fits together
Simplified — the shape of the system rather than every service in it.
-
Customer
- iOS app
- Android app
- Live tracking
- Push notifications
Browse, order and pay, then track against states that mean something, with estimates that are updated rather than defended.
-
Restaurant
- Tablet app
- Order queue
- Menu & availability
- Pause control
A terminal designed for a kitchen mid-service: accept or reject in one tap, mark ready, and stop new orders when necessary.
-
Courier
- Courier app
- Location updates
- Navigation handoff
The job in sequence — collect, confirm, deliver — with as little interaction as possible while moving.
-
Platform
- Order state machine
- Dispatch service
- Payments & settlement
- Analytics
One state machine and one dispatch service, with customer payment, restaurant settlement and courier earnings all derived from the same order record.
The single most important decision: the order state machine lives on the server and the three apps are views. Every marketplace that lets clients hold their own state ends up reconciling three accounts of the same delivery.
Solutions
The three apps and what ties them together
One order state machine on the server, three interfaces onto it. Nothing is allowed to hold its own idea of where an order has got to.
-
Customer app
Browse, order and pay, then track against honest states. Estimates are conservative and updated when reality changes rather than held to for appearances.
-
Restaurant terminal
A tablet app for a kitchen mid-service: accept or reject in one tap, mark ready, and pause new orders when the kitchen is underwater.
-
Courier app
The courier's job in sequence — collect, confirm, deliver — with navigation handoff and as little interaction as possible while moving.
-
Dispatch
Assignment that weighs preparation time, courier position and direction of travel, rather than simply picking the closest courier to the restaurant.
-
Live tracking
Courier position and order state to the customer, at a granularity that is genuinely useful without pretending to more precision than exists.
-
Payments and settlement
Customer payment, restaurant settlement and courier earnings from the same order record, so the money and the history never disagree.
Key capabilities
What it does day to day
Six capabilities across the three sides.
| Capability | Runs | Refresh | What it does |
|---|---|---|---|
| Ordering | Customer | Real time | Browse, order and pay, with a conservative estimate given at checkout |
| Kitchen terminal | Restaurant | Per order | Accept or reject in one tap, mark ready, pause when the kitchen is underwater |
| Courier job | Courier | Per assignment | Collect, confirm, deliver, with navigation handoff and minimal interaction |
| Dispatch | Automatic | Continuous | Assignment weighted by preparation time, courier position and direction |
| Live tracking | Automatic | Real time | Courier position and order state at a granularity that is genuinely useful |
| Settlement | Automatic | Per order | Customer payment, restaurant settlement and courier earnings from one record |
Integrations
How the moving parts plug in
Everything the three sides do passes through one order state machine.
The three sides
- Customer appOrdering and tracking
- Kitchen terminalAccept, prepare, ready
- Courier appCollect and deliver
Order state machine
- Order statesOne definition, server-side
- Dispatch servicePreparation time and direction
- TransitionsValidated, never assumed
Outputs
- Live tracking
- Settlement
- Restaurant reporting
- Courier earnings
Because settlement is derived from the same order record the customer tracked, what a restaurant is paid and what a customer was charged are two views of one transaction rather than two systems to reconcile.
Security & data
What protects customers, kitchens and couriers
A marketplace holds payment relationships with one side, earnings with another, and home addresses throughout.
-
Payment handling
Card details are held by the payment provider. Settlement and earnings reference the order, never a card.
-
Address exposure
A courier sees a delivery address for the duration of the job and no longer, rather than holding a customer list.
-
Role separation
Customers, kitchens and couriers reach only their own side of an order, enforced server-side.
-
Transition integrity
Order state changes are validated against what is possible, so an order cannot be marked delivered before it was collected.
The brief
Every minute of delay is visible to the person waiting
Delivery is the least forgiving kind of software. The customer watches a map. The kitchen is mid-service. The courier is on a bike. A system that is thirty seconds out of date is wrong in a way the customer can see.
The platform had to keep three apps agreeing about one order, dispatch sensibly when several are ready at once, and be honest with the customer when something slips — which is more useful than an optimistic estimate.
- Customers order and watch progress they can trust
- Kitchens accept only what they can actually make now
- Couriers get sensible assignments, not the nearest pin
- Delays are surfaced early rather than hidden
What makes a marketplace hard
- 01Three sides, each able to break the other two
- 02Restaurants go busy or close without warning
- 03Courier supply and demand rarely match at peak
- 04The estimate given at checkout sets the customer's expectation for good
Process
Built one side at a time, with the kitchen first
The kitchen is the constraint. A marketplace with a beautiful customer app and a terminal no chef will touch has no supply.
-
Time in kitchens
We watched services to understand what a terminal can realistically demand of someone mid-rush. The answer was: one tap, and nothing else.
-
The order state machine
A single definition of an order's states and transitions, on the server, before any of the three apps were built.
-
Customer and courier apps
Built against that state machine, with the customer app deliberately conservative about what it promises.
-
Dispatch logic
Assignment tuned against real timings rather than straight-line distance, including the case where several orders are ready at once.
-
Launch by area
One neighbourhood at a time, so courier supply and restaurant coverage could be balanced before widening.
Technology
Real-time, three ways
Live updates to three different audiences from one order service, with dispatch as its own component.
Customer
- iOS app
- Android app
- Live order tracking
- Push notifications
Restaurant
- Tablet app
- Order queue
- Menu and availability
Courier
- Courier app
- Location updates
- Navigation handoff
Platform
- Order state machine
- Dispatch service
- Payments and settlement
- Analytics
Business impact
What changed across the marketplace
Three things that follow from one order and three honest views of it.
-
Kitchens stay in control
A pause control means a restaurant that is underwater stops taking orders rather than failing them.
-
Sensible courier routes
Dispatch that accounts for preparation time and direction removes couriers waiting at counters.
-
Customers trust the tracker
Conservative estimates, honestly updated, are worth more than optimistic ones that break in front of the customer.
The result
One order, three apps, and no one guessing where it has got to
Customers order and track against states that mean something. Kitchens accept only what they can make. Couriers are assigned by preparation time and direction rather than by distance alone.
Because all three read one order state machine, the platform never has to reconcile three versions of the same delivery.
- Three apps over one order state machine
- A kitchen terminal usable mid-service
- Dispatch weighted by preparation time and direction
- Honest estimates, updated when reality changes
What we would repeat on a marketplace
- 01Design for the constrained side first — usually the kitchen
- 02One state machine on the server; no client keeps its own
- 03Promise conservatively and update honestly
- 04Launch one area at a time and balance supply before widening
Verified reviews
What clients say about our mobile app work
Verified reviews from clients of ours on similar work, published on Clutch. They are not from this project.
-
Mobile App Development
Web & Mobile App Development for a Software Company
Their communication skills and industry knowledge have left a strong impression on us.
Alec Wenzowski
President, Button Inc. Jan 2022 – Ongoing
-
Mobile App Development
Software & Mobile App Development
They were great people with great work ethic.
Henry Popp
Co-Founder, Codedge LLC Aug 2021 – Jan 2023
-
Mobile App Development
Mobile App Development for an IoT Company
The project manager does an excellent job, and the team is always available during the project.
Arjen Schoneveld
Co-Founder, Dexels BV Jun 2021 – Oct 2022
Free discovery call
Have an idea? Let's turn it into AI-powered software.
Book a free discovery call with our experts. Share your idea and we will help you shape the scope, timeline and budget, under NDA.
- Free consultation
- NDA before we talk
- Transparent estimate