Key Takeaways
- Assignment is the first thing in a food delivery app to saturate, because it is a contended write against a finite number of people on motorcycles and there is no cache for a shortage of humans.
- The age of an unassigned order is the most useful number an operator can be shown, and it is almost always the last one anybody builds.
- The offer timeout is the most consequential integer in the system: too short and riders react rather than decide, too long and one unanswered phone holds a live order hostage.
- An offer has to be an exclusive claim with an expiry rather than a message sent to riders, because that single design choice is what makes double assignment impossible instead of merely rare.
- Refusing an order at checkout when a zone has no capacity is the only response to saturation where nobody loses their dinner, and almost nobody builds it because it visibly reduces today’s order count.
Assignment Engine Signals
- Measure time from order acceptance to a rider physically holding the bag, and chart it beside cycle time.
- Make the accept a single conditional write with an idempotency key and one server clock.
- Vary the offer timeout by zone, hour and the ratio of free riders to unassigned orders.
- Group declines by restaurant, hour, area and distance band before blaming any individual rider.
- Decide now what the engine does at minute eight with nobody available, and write the thresholds down.
Real Insights
- Optimizing purely for the shortest cycle time quietly concentrates work on riders already in the dense core, and the periphery stops logging in within a fortnight.
- Punishing rejection does not remove refusal, it moves it somewhere you cannot measure: slow riding, cancellation at the counter, or going offline during the hour you needed most.
- Three of the four races that cause double assignment involve the network rather than the logic, which is why a retried accept must resolve to the same outcome as the first one.
- The preparation estimate belongs in the dispatch trigger rather than on the customer’s screen, because assigning too early manufactures counter waiting and assigning too late manufactures cold food.
- Miracuves builds food delivery dispatch platforms with the offer loop, claim expiry and unassigned queue behaviour already in place, deployed in 6 days of build time for eligible ready-made scopes.
An order is accepted at 19:42:06. The ticket is on the kitchen screen, the fryer is busy, and the customer’s screen says the food is being prepared. Nobody is carrying it. No human being in the city has agreed to carry it.
For the next few seconds the platform decides which riders get asked, in what order, how long each has to answer, and what happens when the third one does not answer either.
Those seconds are where a food delivery dispatch app is built or quietly fails. They are not a screen. They are a loop, a scoring function, a lock and a deadline, and each has a failure mode that costs you a rider or a customer.
Grubhub decides which rider carries which order thousands of times an hour, and that decision is the platform.
The Dispatch Gap Between an Accepted Order and a Rider
Between accepted and carried sits the engine that makes a platform like Grubhub work or fall over under load.
Every order has an interval where the kitchen is committed and the logistics are not. The restaurant is spending money. The customer has a promise. The platform has only a list of candidates and a clock that already started.
What the Order Is Doing While Nothing Visible Happens
It is ageing, and that is the whole content of the state. An unassigned order at 19:42:40 is a different object from the same order at 19:42:06, though nothing changed except the seconds elapsed and the riders who declined it.
Systems model this badly because the order still looks pending. Same status in the app, same ticket on the tablet, nothing saying this one is in trouble. The age of an unassigned order is the most useful number an operator can see, and usually the last one built.
Why This Saturates Before Anything Else
Assignment is different in kind. It is a contended write against a finite physical resource, which is people on motorcycles. Doubling volume doubles the database work and the database copes. It does not double the riders on the road at 19:42 on a wet Friday.
Delivery Dispatch Is a Matching Problem Under a Clock
Strip away the vocabulary and the engine is four things: a candidate set, a scoring function that ranks it, an offer that can be accepted or refused, and a deadline that fires when nobody answers. Every serious dispatch defect is one of those four behaving in a way nobody specified.
Image Source: AI-generated visual by Miracuves
The Candidate Set Is a Filter, Not a Preference
Something decides who is eligible before anything is ranked: riders on shift, inside the zone, with a vehicle that fits, not at their load limit, not already holding an unexpired offer.
Eligibility is written once as a query and never revisited, so the interesting cases are the ones it gets confidently wrong. A rider signed in with their phone in a pocket for eleven minutes. A rider whose shift ends in four minutes.
Available and signed in are not the same state, and an engine that treats them as one spends its offers on people who were never going to answer.
The Sequence, Step by Step
An order becomes assignable, which is not necessarily when it was accepted. The engine builds the candidate set, scores and ranks it, offers to the top candidate, marks that rider as holding an exclusive claim with an expiry, and waits.
Then one of three things happens. The rider accepts and the claim becomes an assignment. The rider declines and the claim releases immediately. Or nothing happens, the claim expires, and the engine records that this rider did not answer rather than that they said no.
After a set number of attempts the order must stop looping and escalate: widen the radius, notify a dispatcher, or flag for a decision. The loop without an exit is the most common dispatch bug in existence, and it presents as an order that was never assigned and never complained about itself.
Every Loop Costs Time You Cannot Get Back
Take a 25-second window and three sequential attempts before escalation. That is 75 seconds before a human is told there is a problem, plus candidate selection, plus whatever notification delivery adds.
Ninety seconds is nothing in a diagram and a great deal in a kitchen, and it is cumulative: the rider who eventually accepts starts riding ninety seconds late. What a platform contains is a different question from how it behaves at 19:42, which is why Which Features Does a Food Delivery Dispatch App Need for Order Assignment, Rider Tracking, and Fleet Control? sits beside this article rather than inside it.
What Goes Into the Score, and the Tension Between the Terms
The scoring function is the opinion your company holds about what a good assignment is, written down in arithmetic. Founders treat it as a technical detail and discover later that it was the most consequential product decision in the platform.
The Terms Worth Having
Six inputs carry almost all the value. Travel time to the restaurant. Direction of travel, because a rider already moving that way beats a closer rider pointed elsewhere. Current load. Time since the last drop. Predicted acceptance. And a fairness term, which stops the other five from eating your fleet.
They pull against each other by design. The nearest rider is often the one just given two orders. The rider most likely to accept is often the one who accepts everything. What matters is that the weights are visible, adjustable by zone, and reviewed against outcomes.
Distance Is Not the Same as Time
Straight-line distance is cheap and routinely wrong in the places that hurt. A rider four hundred metres away with a railway, a river or a divided highway in between is nine minutes away, not ninety seconds away.
Snap positions to a road graph, keep a matrix of travel times between frequent points, and let segment speeds vary by hour. Straight-line distance is an acceptable first filter and a poor final ranking, and the gap is where riders learn your platform does not understand their city.
The Fairness Term Is Not Charity
Idle time deserves weight for a commercial reason. Without it, riders positioned well early accumulate work, stay inside the dense area because they are already moving there, and take the next orders too. Riders at the edge get nothing and keep getting nothing.
That produces a wide spread of earnings within one shift, among people doing the same job with the same availability. The ones at the bottom do not complain. They stop logging in, which removes them from tomorrow’s candidate set.
Why Dispatch Optimized Purely for Speed Loses Its Riders
An engine tuned for one objective, shortest time from acceptance to doorstep, looks excellent for about six weeks. Cycle times fall and the founder concludes dispatch is solved. The damage is happening where that dashboard does not look.
The Loop Nobody Models
Fast assignment favours short trips, because short trips return the rider to the pool sooner. Riders working the dense core get a stream of quick jobs. Riders on the periphery get the long runs, which pay once in the time a core rider is paid twice.
Take an illustrative shift: one rider completes five short drops in two hours while another completes two long ones. After a fortnight the second rider is working elsewhere on Friday evenings, which is the only time you needed them. Dispatch quality and supply retention are one problem at two timescales, and How to Keep Restaurants, Riders, and Customers Happy Simultaneously covers the operational half.
Judge the Score by What the Fleet Looks Like in a Month
Three measurements tell you whether the scoring function is eating your supply. The spread of completed orders per active rider hour inside one zone and shift. The share of logged-in riders who got no offer at all in an hour. And week-four retention, split by week-one earnings.
The Offer Timeout Is the Key Number in Delivery Dispatch
One integer, measured in seconds, sits between a rider getting a real chance to respond and an order ageing while one person’s phone lies face down on a table. It is set casually, copied from whatever the developer assumed, and never revisited because nothing obviously breaks.
Image Source: AI-generated visual by Miracuves
What a Short Window Buys, and What It Breaks
A ten-second window keeps the order moving and stops one unresponsive rider holding it. It also asks a person on a motorcycle, at a traffic light, wearing gloves, to make an economic judgement in the time it takes to read the address. That is a reflex, not a decision.
An accidental decline costs a candidate. An accidental accept costs the order twice, because the rider works out at the counter that the drop is thirteen kilometres away and cancels there, with the food already bagged.
What a Long Window Costs
An exclusive offer means one person’s attention is the whole system’s progress. At sixty seconds, a rider mid-handover or simply not looking holds a live order for a minute at no cost to themselves. Three in sequence is three minutes.
It Is Not One Number, It Is a Small Table
Let the timeout vary by zone, by hour band, by how ready the food is, and by the ratio of available riders to unassigned orders. When the food is on the pass, a short window and a wider simultaneous reach is correct, because asking more people costs far less than a cold bag.
Log every expiry as its own event with the rider, the order age and the attempt number. A rider whose offers usually expire is not declining work, they are not present, and those are different problems wearing the same badge.
Founder Decision Signals
Speed
Measure time from order acceptance to a rider physically holding the bag, not pickup to doorstep. Those seconds are invisible in most reporting and are usually where the lateness was created.
Cost
Every re-offer, expiry and manual escalation is unpriced delay. Count them per hundred orders. A platform placing most orders on the first offer runs a cheaper operation than one placing them on the third.
Scalability
Reads scale with hardware, writes scale with correctness. Position updates can be lossy and frequent; assignment writes must be atomic and few. Separate them early, because that boundary is painful to retrofit.
Market Fit
Batching, surge and wide radii all need density, and in a thin first zone they fire rarely. Decide what the engine does when there is nobody to assign to, because that is where a young platform spends most evenings.
Rejection Is Information, Not Failure
A declined offer feels like a defect and gets treated like one. It is closer to a price signal. A rider reading an offer is judging the distance, the expected wait at the counter and what all of it pays against the next hour spent differently.
What a Cluster of Declines Actually Tells You
Rejections are noise one at a time and an instrument in aggregate. Declines clustered on one restaurant usually mean a wait at the counter riders have learned about and you have never measured. Declines clustered at one hour usually mean a shift change.
Declines clustered on one destination area mean something physical: no parking, a gated compound with a slow guard, a tower with one lift. Declines in one distance band mean the payout there has fallen below what riders consider fair use of twenty minutes. None of those fixes is aimed at the rider.
Why Punishing Declines Makes Dispatch Worse
The instinct is an acceptance rate threshold with consequences attached, and measured acceptance does go up. What happens instead is that riders stop using the decline button.
They accept and ride slowly. They accept and cancel at the restaurant, the costliest cancellation available. Or they go offline during the hour the undesirable orders appear.
Use acceptance history as an input to ranking, which is a prediction, not as grounds for sanction. If five riders in a row decline the same order, the honest conclusion is that the order is wrong, and it should go to a human rather than to a sixth rider.
Double Assignment Is the Defect That Matters
Two riders arriving at one restaurant for one bag is a small bug with a large bill. One wasted a journey and will either be paid for it or resent not being paid. The restaurant has an argument to referee. Both riders learn something they will repeat.
An Offer Is a Claim With an Expiry, Not a Broadcast
The mental model that causes the defect is the notification. If an offer is a message sent to riders, two riders tapping accept is natural and the code cleans up afterwards. If an offer is a short exclusive lease, the second accept has nothing to accept.
This holds even when you deliberately show an order to several riders at once during a rush. Wide reach is a notification strategy; the claim stays singular. The first valid accept takes the lease and every other device is told at once. Riders tolerate losing a race, not arriving at a counter to discover they lost one.
Where the Race Actually Happens
Four situations produce nearly every double assignment. Two accepts inside the same fraction of a second. A re-offer issued as a timeout expires while the first accept is still in flight. A dispatcher assigning manually as the engine places an offer. And a client retrying an accept it never got a response to.
What Atomic Looks Like in Practice
The accept is one conditional write that succeeds only if the order is still offered, still claimed by the rider accepting, and the claim has not expired. One row changed means the rider has the order. Zero rows changed means somebody else does, and the app says so at once.
Three details make that work. The accept carries an idempotency key, so a retry resolves to the same outcome rather than a second assignment. Expiry is enforced at the moment of the write, not assumed by a background job running late. And there is exactly one clock, the server’s.
Properties like these separate a working engine from a demonstration, and they are painful to retrofit. It is one of the honest arguments inside Ready-Made Delivery Food delivery dispatch app vs Custom Development: What Should Food Delivery Startups Choose?: correctness under contention is expensive to discover and cheap to inherit.
The Unassigned Queue, and Refusing Before the Kitchen Starts
When no rider is available the orders do not evaporate, they accumulate, and what that accumulation is allowed to do is one of the defining decisions of the platform. A queue with no policy fails in whatever order the code happens to iterate.
An Old Order Must Never Look New
An order declined four times keeps its original acceptance timestamp when it returns to the queue. If it re-enters looking fresh it sits behind orders that arrived long after it, and the problem compounds for exactly the orders already in trouble.
Priority should be a function of age, promised delivery time and how long the food has been ready, not of insertion order. Something must also happen at eight minutes that did not happen at four, or it is not a queue, it is where orders go to become complaints.
Widen, Escalate, or Hold
Widening the radius is the reflex and the weakest of the three. A rider further away is a slower delivery and a worse match, and pulling them out of their area creates a second hole where they were. Widen in defined steps, with a hard limit.
Escalating to a dispatcher is stronger, because a person can call the restaurant to slow a kitchen, ask a rider directly, or pass one order to an external courier. Holding is legitimate too, when the food is six minutes away and there is nothing to assign yet.
Refusing at Checkout Is the Humane Option Almost Nobody Builds
There is a fourth response and it is the only one where nobody loses their dinner. When a zone has no realistic capacity, stop selling in it. Not with an error after payment, but at the cart, before the kitchen is committed.
That means answering a question the engine is never normally asked: if an order for this restaurant arrived right now, could it be placed? It is a capacity estimate, computed from riders currently free, orders queued and prep times in flight. Easy to compute, hard to agree to, because it visibly reduces today’s order count.
The alternative is worse and merely less visible. You take the order, the kitchen cooks it, nobody collects it, and the restaurant absorbs the argument about cold food. How capacity and fees interact there belongs to how the revenue lines are structured.
Batching Only Exists Above a Density Threshold
Carrying two orders on one route is the clearest way to lower the cost of a delivery without lowering what the rider earns. It is also the feature founders specify earliest and use least, because its precondition has nothing to do with software.
The Precondition Is Density, Not Code
A batch needs two orders from the same restaurant, heading in a compatible direction, placed close enough in time that neither waits unreasonably. The measurement that matters is orders per restaurant per ten minutes, not orders per day.
Respectable citywide volume spread across two hundred restaurants produces batchable pairs a handful of times an evening. Build it when your own data shows the pairs exist; until then the same effort spent on the offer loop returns more, which is the pattern behind most of our food delivery solution work.
The Detour Budget and Who Pays for the Saving
Batching moves cost rather than removing it. The platform saves a route, and the customer whose order was collected first and dropped second pays for it. They ordered earlier, receive later, and nothing in their app explains why.
So the budget has to be explicit before the first batch forms: maximum added minutes for the first customer, maximum added distance, a cap on concurrent bags, and a default that the first order placed is the first dropped. Without guardrails, batching converts a margin gain into a refund several weeks later.
Saturation Is a Product Decision, Not a Technical One
Sooner or later demand exceeds the fleet. Not because anything broke, but because it rained or a match ended. The engine cannot solve a shortage of people. What it can do is make the shortage explicit so a human chooses a response.
Three Honest Responses When Demand Exceeds the Fleet
| Response | What it protects | What it costs |
|---|---|---|
| Quote longer times honestly | The kitchen and the customer expectation, because food is cooked against a realistic collection time | Some customers abandon the cart, and your times look worse than a competitor who is lying |
| Close intake in the zone | Every order already queued, which stops new arrivals competing for the same riders | Lost revenue for a window, and restaurants watching their tablet go quiet |
| Raise rider pay for the period | Supply, by making the next hour worth logging in for at short notice | Real money per order, and an expectation that is difficult to withdraw later |
The fourth response is the default and the one to refuse: keep quoting the same delivery time and let the queue absorb the difference. It requires no code, no meeting and no announcement, which is precisely why most platforms do it.
Customers promised thirty minutes who waited seventy do not return at the same rate. Restaurants watch food they cooked correctly become a complaint about them. Choose one of the three honest responses in advance and have the engine surface the threshold rather than hide it.
Restaurant Readiness Is an Input to Dispatch
The preparation estimate is usually treated as something to show the customer. It is far more valuable as the trigger deciding when an order becomes assignable at all.
Assign Too Early or Too Late and Somebody Pays
Assign the instant an order is accepted and the rider reaches a kitchen that has not started plating. They stand at the counter for eleven minutes, earning nothing, forming an opinion that reappears later as a declined offer. Assign too late and the bag sits under a lamp.
Work backwards instead. Take the predicted ready time, subtract predicted travel time for a likely rider, and start the offer loop there, with a margin because the loop itself takes time. That means holding both estimates at once and reacting when a kitchen revises one.
Correct the Estimate From What Actually Happened
Store predicted ready time and actual pickup time for every order, by restaurant and by hour. Two different problems fall out of that table. A restaurant consistently six minutes optimistic has a bias, and bias is easy: shift their estimate and tell them you did.
A restaurant whose ready times swing between four and twenty minutes has variance, and no shift fixes variance. That kitchen needs a buffer, and possibly a policy where the order is only offered once someone confirms the food exists. Catalogue accuracy sits underneath all of it, as in The Out-of-Stock Trap: Why Cheap Delivery Scripts Ruin Restaurant Relationships.
Tracking and Load Are Both Downstream of Assignment
Tracking gets specified as a feature with a map in it. It is more accurately a rendering of the assignment state machine, and the traffic underneath it follows from the same place.
The Map Is a Rendering of the State
Before assignment there is no rider, so there is nothing to draw. A map with no moving dot is worse than a line of text saying a rider is being found, because an empty map reads as a broken app. Never use the restaurant’s location as a stand-in for a rider who does not exist yet.
Show the state in words beside the map, and say when a batched route means the rider is briefly moving away. After delivery the map is irrelevant and the named timestamps are everything, because they are what lets anyone answer where the twenty minutes went.
Many Cheap Reads, Few Precious Writes
Three hundred riders reporting a position every five seconds is sixty writes per second, all evening, each obsolete within seconds. None of it needs to be durable the way an order is durable. Keep the latest position in an ephemeral store, stream it to subscribers, and persist only a downsampled track, which is the pattern behind Sub-2 Second Tracking: Load-Testing GPS Delivery Updates on Flutter and Laravel.
Assignments are the opposite: a few hundred an hour, each contended, serialized, auditable and never lost. A position update must never block one, because the location firehose is loudest exactly when the assignment write matters most. That separation is much of what The 36-Month TCO Comparison: SaaS Delivery Builders vs. Owned White-Label Engines and Migrating from SaaS to Owned Infrastructure: A Peak-Hour Performance Comparison are really about.
Treating an offer as a notification
If an offer is a message rather than an exclusive claim with an expiry, two riders can accept the same order. The claim, the expiry and the conditional write are the feature. The push notification is only how the rider finds out.
Setting one offer timeout and never revisiting it
The window that works in the afternoon is wrong at eight in the evening, and wrong when there are four riders for thirty orders. Vary it by zone, hour and supply ratio, and log every expiry so you can tell absence from refusal.
Penalizing rejection instead of reading it
Attaching consequences to acceptance rate does not remove refusal, it hides it. Riders accept and ride slowly, cancel at the counter, or log off during the hour you needed them. Rank with predicted acceptance, never sanction with it.
Letting a re-queued order look brand new
An order that has waited nine minutes must keep its original timestamp when it returns to the queue. Otherwise it sits behind orders that arrived after it, and you have manufactured starvation for the orders already failing.
Building batching before density exists
Batching needs two orders from one restaurant going the same way within a few minutes. In a thin zone that pair rarely forms, so the feature fires twice a night. Measure orders per restaurant per ten minutes first.
Having no answer for zero available riders
Widening forever is not a policy. Decide what happens at each threshold: widen in defined steps, escalate to a dispatcher, hold while the food finishes, or stop taking orders at the cart before a kitchen cooks something nobody will collect.
Final Thoughts: The Few Seconds You Cannot Buy Back
The assignment engine is where Grubhub either earns its margin or loses it.
Everything visible about a food delivery platform can be rebuilt later. Menus restructured, apps redesigned, fees changed in an afternoon. The assignment engine is the one piece where early decisions keep charging you, because they end up embedded in what your riders believe about you.
The questions worth settling first are not about screens. What is in the score, and what it does to the bottom half of the fleet. How long the offer window is, and what changes it. What makes the accept atomic. Whether you will refuse an order at checkout rather than let a kitchen cook something nobody collects. Starting from a white-label delivery dispatch app means tuning those behaviours rather than discovering them, and what the 6-day deployment covers is build time for eligible ready-made scopes, not a calendar promise.
If you are scoping this now, the most useful hour available is walking through your own zone at 19:42 on paper: how many riders, how many orders, and what the engine does when the answer is nobody. That is the conversation we have on a consultation call, alongside the food delivery app development work that follows and the team that builds and hands over the platform.
FAQs
How do I build an app like Grubhub with a delivery dispatch engine?
The engine builds a set of eligible riders, scores and ranks them, offers the order to the top candidate as an exclusive claim with an expiry, and waits. The rider accepts, declines, or lets the claim expire. After a set number of attempts the order has to escalate rather than loop. Every one of those steps consumes seconds while the food is already cooking.
How long should a food delivery dispatch offer timeout be?
It should not be a single number. A ten-second window asks a rider at a traffic light for a reflex rather than a decision, which produces accidental accepts that get cancelled at the counter. A sixty-second window lets one unanswered phone hold a live order for a minute. Vary it by zone, by hour, by how ready the food already is, and by the ratio of free riders to unassigned orders.
Should delivery dispatch offer an order to one rider or many?
Showing an order widely is a notification strategy and it is often correct during a rush, because asking more people costs far less than a cold bag. What must not change is the claim. Only one rider can hold the order at any moment, and the first valid accept wins while every other device is told immediately. Wide reach with a singular claim is safe. Wide reach with a shared order is not.
How does delivery dispatch stop double-assigning an order?
Make the accept one conditional write that succeeds only if the order is still offered, still claimed by that rider, and the claim has not expired. One row changed means they have it, zero rows means somebody else does. Add an idempotency key so a retried request cannot create a second assignment, enforce expiry at the moment of the write, and use the server clock rather than the phone’s.
Should riders be penalized for declining orders?
No. Attaching consequences to acceptance rate raises the measured number and destroys the signal underneath it. Riders stop declining and start accepting then riding slowly, cancelling at the restaurant where the food is already cooked, or going offline during the exact hour the difficult orders appear. Use predicted acceptance to rank offers, never to sanction people, and read declines as pricing information.
What should happen when no rider is available at all?
Four things are possible and only the first is a reflex. Widen the radius in defined steps with a hard limit. Escalate to a human dispatcher who can call the kitchen or reach a rider directly. Hold, if the food genuinely is not ready. Or refuse the order at the cart before the kitchen commits. Refusing early is the only option where no food is wasted and no relationship is damaged.
When does batching two orders onto one rider actually make sense?
Only above a density threshold. A batch needs two orders from the same restaurant heading in a compatible direction within a few minutes of each other, so the measurement that matters is orders per restaurant per ten minutes, not citywide volume. Below that threshold the feature fires rarely and consumes engineering the offer loop needed more, and without a detour budget it trades a margin gain for a refund.
When should a rider be assigned relative to when the food is ready?
Work backwards from the predicted ready time. Subtract the predicted travel time for a likely rider, add a margin because the offer loop itself takes time, and start offering then. Assigning at acceptance leaves riders standing at counters earning nothing. Assigning late leaves cooked food under a lamp. Store predicted against actual pickup times per restaurant so you can separate a fixable bias from real variance.
Miracuves is an independent software development company. We are not affiliated with, connected to, sponsored by, or endorsed by any company or product named in this article.
Terms such as “X Clone” are used descriptively. It is how the software industry refers to building a platform with functionality comparable to a known service, and how clients search for it.
The entire design and codebase of our products is built by our own team. Our products contain no code, design, graphics, or content originating from any third-party website or applications.
All third-party names and marks referenced in this article are the property of their respective owners, referenced solely to identify the services discussed.
