Almost every QR code on a restaurant table leads to a PDF of the menu. That solves printing costs and nothing else. Actual ordering from the table is a different problem, and the hard part is not the customer's screen. It is what happens in the kitchen thirty seconds later.
We built this for a restaurant platform that now runs five venues in Rabat. Here is what the flow turned into once it met a real service.
One code per table, not one per venue
The code has to identify the table, not just the restaurant, or the order arrives with no idea where to deliver it. The owner generates and prints one code per table from the back office. That sounds obvious written down, and it is the detail that decides whether a waiter can act on an order without asking the room who ordered the pasta.
No confirmation step
Our first version had a cart and a confirm button, copied unthinkingly from e-commerce. It was wrong. A guest at a table is not checking out; they are ordering a drink the way they would by raising a hand. Every extra tap is a chance to abandon, and abandonment here means the guest gives up and waits for a waiter, which defeats the whole feature.
The version that works is one tap. Choose the dish, it is ordered, the kitchen sees it. The cost of a mistaken order at a table is trivially recoverable because there is a human standing ten feet away, which is exactly why the e-commerce safety rail was the wrong pattern to import.
The kitchen needs its own surface, and its own verb
The chef does not need the full order list. The chef needs the dishes that are not yet cooked, and one action: mark this ready for service. Not "complete", not "done". Ready for service, because the dish is finished and now belongs to the waiter, not because the transaction is over.
Getting that vocabulary right shaped the data model. An order is not a single state machine; each line moves through preparation independently. A table's starters can be ready while its mains are still cooking, and the interface has to show that without the chef doing arithmetic.
Live, or it does not work
A kitchen display that requires a refresh is a kitchen display nobody trusts. Orders push to the kitchen over a live connection the moment they are placed, and status changes push back to the floor the same way. We use Socket.IO for this, on the same Node process that serves the site.
The requirement this creates is reconnection. Kitchen tablets lose wifi. The client has to reconnect and resynchronise state without a human noticing, because a chef will not debug a socket. Assume the connection drops, and design the recovery before you ship.
Five roles, because a restaurant has five jobs
Owner, cashier, waiter, chef, guest. Each sees a different surface, and each is authorised server-side on every request. A waiter cannot open the takings. A chef cannot close a bill. This is not a security theatre exercise: it is how the software stops being a source of arguments between staff about who changed what.
The cashier closes the bill and, if the venue runs a loyalty programme, points are credited at that moment. Tying loyalty to payment rather than to ordering is deliberate, since an order can be cancelled and a payment usually is not.
What we would tell a restaurateur
QR ordering does not replace waiters, and pitching it that way is how it fails. It removes the dead time: the wait to catch someone's eye for a second drink. Order volume tends to rise for exactly that reason, which is the actual business case, not staff reduction.
And it only works if the kitchen surface is genuinely good. The guest experience is the easy half. If you build this, budget your attention accordingly. We build it as part of web platform work, and the kitchen screen takes more iterations than the menu does.