Restaurant software is judged in a two-hour window, twice a week. Everything else is rehearsal.
That framing changed almost every decision we made building Radius, our restaurant OS. Here's the build log version — the constraints that turned out to matter, and what we did about them.
Constraint 1: the network is not reliable, and nobody cares
Venue wifi fails. It fails at the worst time, because the worst time is also when the building is full of phones.
The naive architecture — a web client talking to an API for every action — turns a thirty-second outage into a stalled service and a queue at the till. So the client became optimistic and local-first for the critical path: taking an order, moving a table, closing a bill. Those actions write locally, render instantly, and sync when the connection returns.
The hard part isn't the offline write. It's conflict resolution that a stressed human can understand. Two devices modify the same table; the merge has to produce something a floor manager can look at and immediately trust. We ended up making order lines append-only with explicit voids, rather than mutable state — a much duller data model that has the enormous virtue of merging predictably.
Constraint 2: the interface is used by someone walking backwards
Nobody using this software is sitting down. They're mid-service, holding something, half-listening to a colleague.
That killed several designs we liked. What survived:
- Big targets, few of them. The five actions that happen a hundred times a night are always one tap away. Everything else can be two levels deep — it's used twice a shift.
- No confirmation dialogs on the hot path. Undo instead. A confirm step costs a second every time; undo costs a second only when someone's wrong.
- State readable at arm's length. Table status legible without focusing. Colour is not available to us — the brand is monochrome — so the system leans on weight, fill, and position instead. That constraint made it better.
Constraint 3: training time is approximately zero
Front-of-house turnover means someone new uses this on their first shift, with about four minutes of instruction from a colleague who is also busy.
So the product can't have a manual. The design rule became: if it needs explaining, it's wrong. In practice that meant deleting configuration options rather than adding tooltips, and defaulting hard rather than asking.
Every setting you add is a decision you've moved from your team to someone else's worst evening.
What we'd do differently
Two things.
We modelled payments too late. Splitting bills is genuinely gnarly — by item, by share, partial cash, one card declining halfway — and we discovered its shape after the order model was settled. Payments should be a first-class citizen in the data model from day one, not a layer on top of a completed order.
We under-invested in the reporting side early. Owners judge the system on the operational surface, but they renew on the numbers it gives them on Sunday morning. That reporting layer earns its keep, and it's cheaper to build when the event stream is designed with it in mind.
The takeaway that generalises
For operational software, the requirements that matter don't come from the feature list. They come from the worst two hours of the week: the network, the posture of the user, and the training budget.
Build for that window and the rest of the week takes care of itself. Build for the demo and you'll find out on a Saturday.
See the rest of what we've built in Products, or tell us about your operation.