The brief looked like a standard ordering app: menu, cart, payment, kitchen display. The part that actually determined the architecture was a thermal printer bolted to a wall in each kitchen, and the fact that it was not going anywhere.
The kitchen does not want a screen
Front-of-house was happy to move to tablets. The kitchen was emphatically not — a screen that can go dark, freeze, or need a reboot mid-service is a liability when forty tickets are in flight. The existing printers, ugly as they are, never go down and never need training. We kept them as the primary interface for the kitchen and built the display screen as a secondary view for tracking, not the record of truth.
Order state has to survive a dead connection
Sites had unreliable internet, some of them badly. An order placed at the till has to reach the kitchen printer even if the site's connection drops for thirty seconds, and it has to reach it exactly once — a duplicate ticket for a table of ten is a genuine problem on a Friday night.
- Local queue at the till — orders print from a local buffer first, and sync to the cloud when the connection allows.
- Idempotency key per order — generated at creation, so a retried sync cannot produce a second ticket.
- Reconciliation job — runs nightly, flags any order that printed locally but never confirmed in the cloud, for a human to check.
The integration nobody budgets for
Thermal printers speak a decades-old protocol family with enough manufacturer variation that "supports ESC/POS" is not a guarantee of anything. Two of the group's six sites had printers that silently truncated long item names. We found this in the second week of rollout, not in testing, because nobody had a truncated name in their test menu.
The integration that looks solved on paper is the one worth testing with the actual hardware, in the actual kitchen, before the second site goes live.
What shipped
A tablet-based till, a cloud order and menu service, and a print bridge running on a small local device per site that talks to the printer directly and only needs the internet for sync, not for taking an order.
What we would do differently
Test with real hardware from week one rather than a printer emulator. The emulator was faithful to the specification and unfaithful to the actual printers, which is the worst kind of test double — confident and wrong.