Open almost any delivery app and watch the tracking screen. An icon edges along a route, a countdown ticks, the status flips to "on the way." A surprising amount of that can be theatre — progress interpolated from a timer, because a moving icon feels better than a still one. On Saturdays, a food delivery platform, I made the opposite call: the tracking screen shows what the server knows, and nothing it doesn't.
Why fake progress is tempting
The honest state of a food order is lumpy. Nothing visible happens for minutes while a kitchen cooks, then several things happen at once. Product instinct says fill the gaps: animate a progress bar, advance the status on a schedule, drop a rider icon near the restaurant the moment the order is accepted.
It works — until the timer and reality disagree. The screen says a rider is on the way and no rider has been assigned. The icon is moving and the food is still on the pass. Now the customer has been told something false by the one screen they trust to be accurate, which does more damage than a still screen ever could. They contact support, and support is looking at a different truth than the customer is.
The rule: render events, not guesses
Saturdays' tracking follows one principle: every change on the tracking screen corresponds to something that actually happened on the server.
- Status comes from the state machine. The order moves placed → confirmed → preparing → ready → picked up → out for delivery → delivered, and the screen shows a step only after that transition has committed. No client-side clock advances it.
- The rider appears when a rider exists. The rider icon shows up only when the server reports an assignment. Until then, the screen honestly says the order is being prepared.
- An ETA is an estimate. It's worth showing — but it's a number, not permission to animate a rider who isn't there.
Making "honest" also feel live
The objection is that an honest screen feels dead. It doesn't have to. The fix is to make the truth arrive fast, not to invent it.
Tracking runs over WebSockets, with Django Channels and Daphne on a Redis channel layer. When an order transitions on the server — the restaurant marks it ready, a rider is assigned, the rider picks it up — the event is pushed to the customer's open connection straight away:
# after the transition has committed
async_to_sync(channel_layer.group_send)(
f"order.{order.public_id}",
{"type": "order.update", "status": order.status},
)
(Simplified.)
The screen updates moments after the real event. There's no polling interval to hide behind and no timer to drift out of sync, because the timer never existed. The gaps where nothing changes are real gaps — and "your food is being prepared" is a perfectly good thing to show during them.
Where optimism does belong
This isn't an argument against optimistic UI. When users act on their own data — adding to a cart, saving a preference — updating instantly and reconciling in the background is exactly right, because the user is the source of truth for their own intent.
The line is ownership. Be optimistic about what the user just did. Be strictly honest about what other people and systems are doing — the kitchen, the rider, the payment gateway. Order tracking is entirely the second kind.
The takeaway
A status screen is a promise. Fill it with events the server has committed, deliver those events in real time so honesty never feels slow, and treat estimates as estimates. The screen will be quieter than a faked one — and it will be right every time someone looks at it.
The full order flow behind that screen — the state machine, the rider layer, the realtime stack — is in the case study.
👉 Read it: www.divyakush.com/projects/saturdays
Divyakush Punjabi — Full-Stack & AI Systems Engineer
🌐 https://www.divyakush.com · 💼 LinkedIn · 💻 GitHub
Top comments (0)