The kitchen and dispatch were running on a shared spreadsheet — one lag, one cell collision, one mis-typed address and the whole shift stalled. We built the operational loop as real software: an order-handling app for the kitchen, a routing app for drivers, wired to the same live state.
Ops was a shared Excel — orders on one tab, drivers on another, addresses copy-pasted by hand. Every shift picked up the same drift: stale rows, cell collisions, one-off typos that moved pins to the wrong postcode.
It held together on good days and broke under any spike. The ask was a real operational tool — owned by Pottsalat, fitting how they actually work.
Locking, merge conflicts, silent overwrites during the lunch push.
Same order, two states, reconciled verbally.
No driver-side tool — addresses relayed, sequences improvised.
We designed the app pair around the actual operational loop: order arrives → kitchen confirms → route is assigned → driver delivers. One state object flows through it; both apps read and write to it in real time.
We shadowed real shifts before writing a line of code — the kitchen dialect, the dispatch gestures, the micro-frustrations of the current setup. The apps are shaped by that, not by a generic ops template.
Incoming, in progress, ready. Big type, no dropdowns, gloves-safe controls.
Sequenced stops, address-verified pins, handoff confirmation — works on a shift phone.
Both surfaces react in the same second; no polling, no reconciliation calls.