How this QR menu is built

A guest scans the code on the table, orders from their own phone, and the ticket appears on the kitchen screen before the waiter would have finished walking to the till. The kitchen bumps it, and the guest's phone says the food is on its way. One system, two directions, no app to install.

The business version, in one paragraph

A waiter takes an order, walks to the terminal, types it in, and the kitchen starts cooking: two to four minutes of walking per order, plus the mistakes that come with retyping. Here the guest's phone is the terminal. The order is on the kitchen screen in a fifth of a second, already split between the hot line, the grill and the bar, with allergies and "no onion" attached to the right dish. The waiter's time goes back into the dining room, where it earns money.

What it actually does

Shared table cart. Two phones at one table build one order and see each other's additions live.
Station routing. An order splits into tickets — soup to the hot line, wine to the bar — the way a kitchen really works.
86 list. The kitchen marks a dish sold out and it greys out on every open phone in the room instantly.
Calls and bills. Water, cutlery, the bill — with a timer the floor manager can see.
Split by person. The bill can be split by who ordered what, because the cart remembers.
Bad wi-fi mode. Turn on "demo: bad wi-fi" in the cart and half the requests die. The order still arrives exactly once.

Measured on this stand

—ms p50 order → screen0 samples

—ms p95server + network + paint

—ETA within 2 minhuman-run orders only

2orders today0 from real visitors

Step	Paper / walk to the till	This stand
Order reaches the kitchen	2–4 min of walking and typing	under a second, measured above
Sold-out dish	guests keep ordering it until every waiter is told	greyed out on every phone at once
Allergy note	repeated verbally, sometimes	attached to the dish on the ticket
Split bill	arithmetic at the table	computed from who ordered what
Weak wi-fi	order retyped, sometimes twice	queued locally, delivered once

Architecture

One Node process holds the HTTP API, the websocket hub and the state machine; SQLite holds the data and the event log. No broker, no cluster, no external service.

Why an event log and not just pub/sub

Kitchen tablets sleep, screens get carried through the walk-in, phones lock. A plain broadcast loses whatever happened while a screen was away. Every state change here is appended to an events table first and broadcast second, so a reconnecting screen says since=1841 and receives the missed tickets in order before live traffic resumes.

Why the order carries an idempotency key

A phone on a bad connection cannot tell "the request never arrived" from "the answer never came back". So it retries — and a naive kitchen cooks the steak twice. Each order carries a key generated on the phone; the database has a unique index on it. Retry as often as you like: one steak.

Why the cart belongs to the table

People do not order individually; they order together. The cart is keyed to the table visit, every line remembers which phone added it, and that single decision gives you live "Basil added hummus" updates and a bill that can be split by person without anyone doing arithmetic.

Where the “ready in ~14 min” comes from

Not from a field in the menu. Each station's current queue is summed in cooking minutes, divided by three pairs of hands and capped at ten minutes, then added to the longest dish in your own order: eta = max(dish) + 0.5 × rest + min(10, backlog / 3). Press Rush hour on the home page and watch the promise move. The panel above compares promise to reality — and counts only orders a human actually ran on the kitchen screen, because the synthetic tables cook on a compressed clock.

Why the dish pictures are vectors

Stock food photography is somebody else's plates and roughly 200 KB each. All 48 dishes here are drawn by a small generator from a palette and a shape archetype — about 1 KB each, inline in the HTML, sharp on any screen, and legally ours. Zero image requests on the menu page.

What is honest about this demo

Payments are test mode. The bill, the split and the receipt are real logic; no processor is involved and the button says so.
Synthetic tables. Tickets marked sim come from a generator so the kitchen screen is alive at 3 am. They never take the featured table.
Auto-cook. If a visitor orders and walks away, a virtual cook advances that ticket after a minute so the story completes. Anything a human bumps stays human.
The restaurant is invented. Menu, prices and illustrations were made for this stand.
The kitchen screen is public here. In a real venue it sits behind a staff login; on a demo it has to be touchable, so guest notes are capped and filtered instead.

What it costs to run

One Node process and one SQLite file. No queue, no Redis, no third-party API.
Around 60 MB of RAM; the database of a busy demo day stays in single-digit megabytes.
Everything resets every 6 hours from the reference menu in the repository, so the demo cannot rot.

Things that broke while building it

Sleeping tablets lost tickets. Fixed by the event log and since= replay described above.
Duplicate orders on retry. Fixed by the idempotency key and a unique index — the retry now returns the original order.
Latency numbers that flattered us. The first version measured only server time. It now adds the transport (measured by an ack round trip) and the client's own paint time, so the number on this page is the whole journey.
Synthetic tables stealing the demo table. The simulator now refuses the featured table, and a real scan evicts a synthetic guest.

Demo home Kitchen screen Waiter screen Admin · demo/demo Live stats JSON