What a restaurant POS has to get right

A waiter is standing at table nine with four drink orders in his head and a customer asking for the check at table two. He has about four seconds of patience for your software. If the screen he needs is two menus deep, he will write the order on his hand and enter it later, wrong, from memory. That single behavior is where most restaurant systems quietly fail, and no dashboard will ever show it to you.

We built a sample restaurant POS interface as part of the set at /demos. It is a mock-up with invented dishes, invented tables and invented totals, no kitchen and no cash drawer attached to it. The point of building it was to work out the shape of the thing: which screens exist, what sits on the first tap, what the closing screen has to prove at the end of a shift.

The common path has to be brutally short

Most of the work in a restaurant is the same three actions repeated a few hundred times a night. Open a table. Add an item. Send it to the kitchen. Everything else, the split checks, the comps, the returns, is rare by comparison and can afford an extra tap. Systems get designed backwards when someone lists every feature and gives each one equal weight in the navigation.

So the layout question is not what the system can do, it is what is reachable with a thumb while walking. In the sample interface, the table map is the home screen and the item grid is one tap away from any open table. Modifiers open in place, not on a new page. Nothing about that is clever; it is just the result of deciding which action is the frequent one and refusing to bury it.

Things a point of sale has to get right, in roughly this order:

WITHOUT

• Every feature equal in the menu
• Order created on the server
• Cloud printing to kitchen
• Audit trail added later

WITH

• Frequent action on the first tap
• Order created on the device
• Kitchen printer on local network
• Audit trail written with the sale

• sending an order to the kitchen in under three taps, every time
• modifiers and split checks without leaving the table
• every void, discount and comp attached to the person who did it
• printing a kitchen ticket even when the connection is gone
• a fiscal receipt sequence with no gaps and no duplicates
• a shift close that a manager can reconcile against the cash in the drawer

When the connection drops

Internet in the DR is good until it is not, and it tends to fail at the hour you can least afford it. A POS that stops taking orders because a cloud API timed out is worse than a notebook. The design rule is that the terminal owns the shift while it is happening: orders are created locally, given an identifier generated on the device, and queued. The server catches up when it can.

That has consequences you have to accept up front. Receipt numbers cannot be assigned by the device, because two terminals offline at the same time will both claim the same number, so those come from the server and the printed ticket has to tolerate the wait. Kitchen printers belong on the local network, talking to the terminal directly, so a fried modem does not stop food from cooking. And if two waiters touch the same table while offline, the merge is a business decision, not a technical one, and somebody has to decide it before you write the code.

Closing the shift is the real product

The screen that decides whether a restaurant keeps the system is the one at two in the morning. Cash counted, card batch totals, tips declared, voids listed with names next to them, and the difference between what the system says and what is in the drawer. If that number is unexplainable, the owner stops trusting every other number the system produces, including the ones that were fine.

So the audit trail is not a compliance checkbox bolted on later. It has to be written at the same moment as the sale: who opened the table, who moved the item, who applied the discount, what time the ticket printed. Retrofitting that into a system that treated orders as mutable rows is painful, and we would rather say so than pretend it is a small migration.

None of this is exotic. It is the ordinary discipline of building for a room full of people who are moving fast and do not care about your software. The sample interface at /demos exists so a restaurant owner can look at the shape of it and tell us where their operation is different, which it always is, before anyone writes a line of production code.