How to Build an App Like Grubhub: Dispatch Features and Build Order

Six weeks into the build, the customer app is the best-looking thing the team has made. The menu scrolls, the cart animates, the address picker snaps to a pin. In the stand-up somebody asks whether an order actually works yet, and the room goes quiet, because nobody can answer that without three qualifications.

An order can be created. It cannot be accepted, because there is no restaurant panel. It cannot be assigned, because there are no riders in the system. It cannot be paid out, because nothing has ever completed. The team has spent six weeks on the one surface whose correctness cannot be demonstrated alone.

This is the most common way a delivery project loses its first quarter, and it is not a failure of engineering skill. It is a failure of build order. A four-sided platform has a property most software does not: almost nothing in it can be tested in isolation, because every behaviour that matters needs three of the four parties at once.

This article is about the dependency order inside the build of a food delivery dispatch app. What has to exist before what, why the sequence that feels natural is the wrong one, and what makes each stage something you can verify rather than something you can only look at.

Nothing in a Grubhub-style platform is testable until one dependency exists, and it decides the whole build order.

The Dependency That Governs a Delivery Dispatch Build

A team building toward Grubhub discovers this dependency early or rebuilds around it late.

State it once, early, and let it decide the plan. You cannot test dispatch without riders in the system. You cannot test payouts without completed orders. And you cannot complete an order without a restaurant that accepts one.

Read that chain backwards and the schedule falls out of it. Payouts depend on completions, completions on deliveries, deliveries on assignment, assignment on riders and on an accepted order, and acceptance on a restaurant that exists with a menu and opening hours.

Nothing Here Is Testable Alone

In most software, a feature is testable the moment it is written. A checkout calculation takes inputs and returns a number. You write the test, you run it, you know.

Dispatch is not like that. The behaviour you care about is an interaction between an order in a state, a fleet with a shape, a zone with a boundary and a clock. An offer that expires after thirty seconds means nothing without something to offer, somebody to offer it to and time passing. How to Build an App Like Grubhub: Inside the Food Delivery Dispatch Engine covers what that engine does. The question here is what has to exist around it before you can tell whether yours works.

The Surface You Start With Decides What You Can Prove

Every build order is a bet about what you can demonstrate in week six. Start with the customer app and week six gives you screenshots. Start with the order and the operator tooling and it gives you a real order that a human accepted and a human delivered, on ugly screens.

Ugly and verified beats beautiful and unknown, because the ugly one tells you whether the hard part works while there is still time to change it.

Build the Dispatch Order Object Before Any Interface

The first thing to build is not a screen. It is the order itself: what it contains, what states it can occupy, which transitions are legal, who is allowed to cause each one, and what gets recorded when each one happens.

Four Applications, One Object

The customer app, the restaurant panel, the rider app and the operations console are not four products. They are four views onto one object, filtered by role and by what each party may see and change.

The customer sees a status and an estimate. The restaurant sees items, a prep clock and an accept action. The rider sees a pickup, a drop and a proof step. The operator sees everything, plus the transitions nobody else may make. Our food delivery solution is organized this way for the same reason: the object comes first and the surfaces hang off it.

Named Timestamps Are Schema, Not Logging

Teams treat this as an afterthought, something to add when support starts asking questions. Put it in the object on day one. Placed, paid, accepted, quoted ready, offered, claimed, rider arrived, handed over, delivered. Each one a named field with a time on it, written by the transition that caused it. A dispatch test then becomes an assertion about a sequence of timestamps rather than a person watching a screen and saying it looked fine.

This is also why the object is worth getting wrong early. Add a state in week two and you edit one enumeration and one transition table. Add it in week fourteen and you edit four applications, their caches, their notification copy, the operations filters and every reporting query you have written since.

Why Delivery Dispatch Needs the Admin Console Early

Nobody wants to build the operations console first. It has no users yet, it will look plain, and it demos badly. Build a usable version of it second anyway, because it is the only surface from which you can create the conditions every other test requires.

The Console Is Your Test Fixture

To test anything at all you need a restaurant that exists, with a menu and hours. A zone with a boundary. A rider account marked available inside it. An order in a known state.

Every one of those is a console feature. Without it, engineers create those conditions by writing rows into the database by hand, so every test begins with a step nobody else can repeat. The console is not overhead beside the build. It is what makes the build testable, and the fleet tooling on the features page is the same surface in its finished form.

Forcing an Order Into a State

The most valuable early console feature is forcing an order into any state directly, with a reason recorded and the actor named. Without it, seeing what the rider app does when an order is cancelled mid-journey means reproducing a whole journey. With it you set the state and watch. Build it with an audit trail, because support will use the same capability in production.

The Restaurant Panel Before the Customer App

An order nobody accepts is not an order. It is a row in a table with a hopeful status. Until something can accept, reject and quote a ready time, the lifecycle has no second step and the whole chain below it stays untestable.

Acceptance Is the First Real Transition

Placement is easy. A customer app creating an order is a form post. Acceptance is where the system first deals with a party who has their own business, their own busy hour and their own reasons to say no.

A first pass needs less than founders expect: an incoming queue with a sound, accept and reject with reasons, an item-level out-of-stock action, a prep time input and a mark-ready action. That is enough to make every downstream test possible. Menu correctness matters later, and The Out-of-Stock Trap: Why Cheap Delivery Scripts Ruin Restaurant Relationships covers what happens when it is treated casually.

Prep Time Is an Input, Not a Label

Teams build the prep time field as a number the restaurant types and the customer reads. That is a display. Its real job is to feed dispatch, because when a rider should be offered the job is a function of when the food will be ready.

Wire it as an input to assignment in the first version, even crudely. Wire it as a label now and you will rewrite dispatch timing later, after the rider app already depends on the old behaviour.

The Rider App Is Where Delivery Dispatch Becomes Real

With an order object, a console and a restaurant panel, the build has a body but no motion. The rider app is where the platform stops being a record of intentions and starts being a thing that moves food across a city.

Offer, Claim, and the First Honest Dispatch Test

The moment two rider accounts are online in one zone, you can finally test the behaviour that will define your platform. Offer to one and hold. Offer to two and see whether both can claim. Let an offer expire and confirm it re-offers. Take a rider offline mid-offer.

None of that was testable an hour earlier. That is why the rider app sits where it does: it unlocks the largest block of previously unverifiable behaviour, which is a better reason to sequence work than which screen a founder wants to show an investor.

Location Is a Build Problem Before It Is a Feature

Rider location looks like a small feature and behaves like a subsystem. It runs in the background on a phone with an aggressive battery policy, it arrives out of order, it vanishes in a basement car park and it costs money every time you turn it into a route.

Decide your update interval, your batching and your handling of stale positions while the rider app is built, not after a tracking screen has been demonstrated at one-second smoothness on office wifi. Sub-2 Second Tracking: Load-Testing GPS Delivery Updates on Flutter and Laravel works through what that costs under load.

The Customer App Last, and Why That Feels Wrong to Everyone

Every instinct in the room objects to this. The customer app is the product in most people’s heads, it is what the brand looks like, and it is the thing a founder can show somebody over dinner. Build it last anyway.

The Demo Argument, and Why It Loses

The case for building it first is that you need something to show. That is a real need and it deserves a real answer, but the answer is not the production customer app.

Design it properly in parallel and demo the prototype. A prototype demos better than a half-wired app anyway, because nothing in it fails in front of an audience. What you cannot fake is an order moving through four parties, and that is what deserves engineering weeks early.

What the Customer App Gains by Being Last

Built last, it is written against a system that already works. Every status it displays is a state that genuinely occurs. Every estimate it shows is computed from timestamps that already exist. Every failure it handles has already been observed happening to somebody.

Built first, it is written against guesses, and half of those turn out wrong once dispatch is real. The feature set it eventually needs is described in Which Features Does a Food Delivery Dispatch App Need for Order Assignment, Rider Tracking, and Fleet Control?, and most of it is only specifiable once the layer beneath behaves.

Seeding and Simulation Are Build Work, Not a Nicety

Here is the piece almost every team skips and regrets. You need the ability to conjure a plausible world on demand, and it has to be a maintained part of the codebase rather than a script on one engineer’s laptop.

A Hundred Plausible Orders on Demand

One command should produce a city: a dozen restaurants with real menus and different prep profiles, a few hundred customers spread across your zones, riders with varied availability, and a hundred orders across a plausible evening rather than all at the same second.

Without it, every engineer tests against a different world and bugs stop being reproducible. With it, a bug report is a seed number and a state, and whoever picks it up sees exactly what the reporter saw.

A Fake Fleet That Actually Moves

A simulated rider is not a row marked available. It is a process that accepts after a delay, moves along a route at a speed, sometimes goes idle, sometimes rejects, and occasionally stops sending location for two minutes.

Twenty of those against your dispatch engine teach you more in an afternoon than a fortnight of manual testing with staff phones on a table. It is also the only honest way to see backpressure before real riders and real customers are waiting.

A Restaurant That Accepts on a Timer

The same applies on the restaurant side. A simulated outlet that accepts after forty seconds, quotes a prep time from a distribution, occasionally rejects and occasionally marks an item unavailable will exercise paths a human tester never reproduces twice.

Teams that treat simulation as first-class work speed up from week five onward, because every later change is verifiable in minutes. Teams that skip it test manually forever. If you are scoping this with an app development partner, put the simulation harness in the statement of work rather than assuming it appears.

The Test Environment Nobody Budgets For

A food delivery dispatch app touches four external systems that all behave differently outside production: payments, maps, notifications and messaging. A safe staging environment is real work and it belongs on the plan.

Test Mode Is Not the Same System

Gateway sandboxes give you deterministic card numbers, which is what most of the build needs. They also differ from production where it hurts: settlement timing, dispute flows, authentication challenges and webhook ordering.

Build against test mode, then treat the first production transactions as their own verification stage, with real money and small amounts. The base platform ships in test mode by design, because live keys belong to your merchant account and nobody can obtain them for you.

Maps Cost Money Per Call

Geocoding, route estimates and distance calculations are billed per request, and an automated test suite is an excellent way to spend a lot of money quietly. A simulated fleet makes it worse, because it multiplies calls by the number of fake riders.

Put a routing interface behind everything early, with a fake implementation for tests and the real provider in production. Small work in week two, unpleasant retrofit in week twelve.

Notifications That Must Not Reach Real People

Every staging environment eventually acquires a copy of real data, and every message gateway will happily deliver a test notification to a real phone at two in the morning. Put a hard gate in the sending layer, not a note in a document.

The safe pattern is an allowlist of destinations outside production plus a log of everything that would have been sent. That log is also the fastest way to test a delivery journey, including the proof step in Grubhub App Security Risks: Delivery Dispatch, Proof and Rider Safety.

Where the Build Order Goes Wrong

The failures below are the same six mistakes, made by capable teams, for reasons that felt sensible at the time. What they share is a preference for work that can be shown over work that can be verified. That preference is rewarded in every status meeting, and on a four-sided platform it produces a project that looks ahead of schedule until the week it obviously is not.

The Order of the Money Work

Money work has its own sequence, and it follows the same dependency logic. Taking money is possible early. Splitting it needs a completed order. Paying it out needs a body of completed orders and a reconciliation period, which is why payouts are always the least-finished part of the platform on launch day.

Take Payment Early, Because It Gates the Lifecycle

Authorization and capture sit at the start of the lifecycle, so they can be built as soon as the order object exists. Build the cash path at the same time, because cash changes what the rider app must collect and what reconciliation must account for.

A platform that handles only cards until week sixteen will discover that cash is not a payment method bolted on at the end. It is a second accounting reality running through the rider, the shift and the float.

Split It in the Middle

Once orders complete, you can compute who is owed what: the restaurant’s share after commission, the rider’s earnings for the trip, the platform’s fees, tax where it applies, and the treatment of a tip.

Build the split as a calculation with its own tests long before anything sends money anywhere. It is pure arithmetic over a completed order, which makes it the most testable part of the money work and the part most often left informal. The lines it handles are set out in how the business model works.

Pay Out Last, and Plan for It to Be Unfinished

Payouts need completed orders across a period, bank details, a statement a restaurant owner can reconcile against their own books, adjustments for refunds and a handling of disputes that arrive after the period closed.

You will not finish that before launch, and you do not have to. What you need on launch day is a correct ledger and a manual process, because a manual payout from correct data is survivable for a month and an automated payout from a ledger nobody trusts is not.

What Can Genuinely Run in Parallel

Every founder reading a sequential plan wants to compress it, and some of that instinct is right. A fair amount of this work parallelizes. The trap is the work that appears parallel and quietly is not.

Genuinely Independent Work

Design, catalogue and menu tooling, notification copy, the seeding harness, infrastructure and the legal and content pages depend on almost nothing. They can start on day one and run the length of the project.

So can the split calculation once the order object is stable, and anything that consumes a completed order rather than producing one. How to Keep Restaurants, Riders, and Customers Happy Simultaneously is a useful companion while that work runs, because it describes the reality the tooling eventually serves.

The False Parallel

Two teams building the rider app and the dispatch engine at once look parallel on a chart. They are not, because the rider app’s behaviour is a response to dispatch decisions, and neither team can test its half without the other.

What they produce is two plausible implementations of a shared assumption and an integration week that becomes three. The honest version is one team building dispatch and the rider app together, with the second team on genuinely independent work.

The Pilot Is a Stage of the Build, Not an Event After It

The most valuable week in the schedule is the one where a real restaurant accepts real orders from real people over a handful of real streets. Teams place it after the build, which wastes most of what it produces, because by then there is no time to act on it.

One Restaurant, One Rider, a Handful of Streets

The pilot that teaches the most is embarrassingly small. One outlet that knows what you are doing. One or two riders who answer the phone. A zone of a few streets. Staff placing real orders with their own money, at real meal times.

Run it while the customer app is still rough. The pilot is not testing the interface, it is testing whether a busy kitchen, a moving rider and a hungry customer can be coordinated by your software. A white-label delivery app shortens the distance to this stage considerably, which is its main practical advantage.

What a Week of Real Orders Tells You

Prep times are quoted optimistically and drift by time of day. Addresses in real buildings are worse than any you invented. Riders park where they can, not where the pin is. Somebody accepts an order and then realizes the main item is off.

None of that surfaces in testing, and all of it changes your product. That is the argument for treating the pilot as a stage that produces requirements rather than a ceremony confirming you are finished.

Name the Exit Criterion Before You Start the Stage

A build order only works if each stage has a definition of done somebody outside the team can check. Otherwise stages blur, work continues everywhere at once, and the sequence exists only on the plan.

The Demonstration Has to Include a Failure

Write each exit criterion as an observable event. The console stage ends when a non-engineer can create a restaurant, a zone and a rider, and force an order into any state, unaided. The rider stage ends when two riders are online, one gets an offer, it expires, the other claims it and the order completes with a proof artifact attached.

A happy-path demonstration proves little on a platform whose value is what it does when something goes wrong, so every stage exit should include a failure: a rejected order, an expired offer, a cancelled delivery, a refund. It is also how to evaluate anyone building this for you. Ask a prospective development partner to demonstrate a rejection and a cancellation rather than a clean order, and you will learn more in ten minutes than from any proposal.

Where a Ready-Made Platform Changes the Sequence

Everything above assumes you are constructing the dependency chain yourself. Starting from a platform that already has it removes the build order problem entirely and replaces it with a different, smaller one.

Configuration Replaces Construction

The order object, its states and its timestamps already exist. Four surfaces already read them. Dispatch already offers, expires and re-offers. Your work becomes zones, fees, commission rules, branding, your own gateway and map credentials, and your catalogue.

That is a different job with a different failure mode. You are no longer at risk of finding in week fourteen that the lifecycle is wrong. You are at risk of configuring a zone or a commission rule that does not match how you intend to operate. Ready-Made Delivery Food delivery dispatch app vs Custom Development: What Should Food Delivery Startups Choose? works through that choice properly.

The Pilot Does Not Go Away

What does not disappear is the pilot. Prep variance in your city, address quality in your buildings, the behaviour of your riders and the tolerance of your restaurants are local facts, and no platform knows them in advance.

Deployment of an eligible ready-made scope follows a 6-day build path, set out on the facts page. Gateway onboarding, developer account review and your courier arrangements sit outside it, and the platform ships in test mode until your keys are in place. Being clear about that boundary is what makes the rest of the timeline honest.

Final Thoughts: Build in the Order That Lets You Find Out

Build order is not a preference. For a platform like Grubhub it is set by what has to exist first.

The sequence in this article is not a style preference. It falls out of one property of the system: almost every behaviour worth having needs three parties to exist before it can be observed at all. Build toward observability and the order chooses itself.

The object first, because it is the most expensive thing to change. The console second, because it creates the conditions for every test. The restaurant panel third, because an order nobody accepts is not an order. The rider app fourth, because that is where the system does something real. The customer app last, against a machine that works. Seeding, simulation and safe staging underneath, and a pilot early enough to change something.

If you would rather skip the construction and go straight to the configuration and pilot problem, that is a shorter road with a different set of decisions. Bring your zone plan, your commission model and your one willing restaurant to a consultation and we will map the sequence against what you already have.

FAQs