What a Restaurant Ordering System Handles on a Friday Night

A QR code on a table and a menu on a phone is a weekend project. We know, because the pleasant part of building a QR ordering system for a Frankfurt venue took a fraction of the time, and everything afterwards was the actual product.

What makes hospitality software hard is that the happy path is trivial and almost nothing on a busy night is the happy path.

The exceptions are the product

List what happens in a real service and the shape of the work becomes clear immediately. Two people at one table both order. A group moves to a bigger table halfway through. Someone joins late and wants to be on the same bill. Someone else wants to pay only for their own food. The kitchen runs out of a dish while three unpaid orders containing it are open.

None of that is exotic. All of it happens nightly, and every one is a decision about state: what an order belongs to, when it becomes final, and who is allowed to change it after that. Get those three wrong and no amount of interface polish rescues the system, because staff will simply stop using it during the hours it was bought for.

Staff have to be able to overrule it

This is the single most reliable predictor of whether hospitality software survives contact with a venue. On a busy night, something will be wrong in a way the software did not anticipate, and a member of staff will need to fix it in front of a waiting customer.

If the only path is to call a manager, cancel the order and start again, the system has failed at the exact moment it was supposed to help. Staff need to move an order between tables, remove an item, apply a correction and reopen something marked complete, without a password dance and without being asked three times whether they are sure.

The counterweight is a record. Every override logged, with who and when, so the owner can review it the next morning. That combination, easy to do and impossible to hide, is what makes it safe to give staff real power.

The connection will drop, usually in the worst room

Venues have thick walls, basements, beer gardens and a hundred phones competing for the same access point. A system that assumes a reliable connection will be unreliable precisely when the room is full.

The requirement is not that everything works offline. It is that nothing is lost: an order taken on a tablet with no signal must be held and sent when the connection returns, and the person taking it must be able to see that it has not gone through yet. Staff tolerate a delay. What breaks trust permanently is an order that silently vanished, because after that happens once nobody believes the screen again.

This is the same argument as offline sync anywhere else, and it has the same economics: decided at the start it is a design constraint, added later it is a rewrite of how the app stores anything.

Who is allowed to say a payment succeeded

Table ordering usually means a customer paying from their own phone, which puts the payment confirmation in the least trustworthy place in the system. A browser can be closed, refreshed, interrupted by a call or tampered with.

So the browser is never the authority. The kitchen is told to make the food when the payment provider confirms the payment to your server, not when a screen in someone's hand says thank you. Getting this backwards produces exactly the two failures a venue cannot absorb: food made and not paid for, or a customer charged for food that never arrived. The mechanics are in the article on payment webhooks.

Paying on site rather than in the app is also a perfectly respectable answer, and for many venues the right one. It removes an entire category of failure, and it is worth deciding deliberately instead of defaulting to in-app payment because it sounds modern.

The kitchen is a different user entirely

Customer screens get the design attention. The kitchen screen decides whether the system is actually used, and its requirements have nothing in common with the customer's.

It is read from a distance, by someone with wet or gloved hands, under time pressure, often at an angle. It needs large type, obvious ordering by time, an unmistakable signal when something new arrives, and no interaction more complex than one confident tap. Anything requiring precision will be ignored, and a printed ticket will quietly reappear.

The same applies to the bar, which is usually forgotten entirely because drinks feel simpler than food. They are not: they are faster, more frequent, and more likely to be ordered by someone standing rather than seated, which means an order arriving from a table and an order taken at the bar have to end up in the same place without anyone reconciling them by hand.