The guest's menu is older than your shelf
A QR menu loads once and sits on a table while stock changes behind it. What has to happen when a guest orders a dish that sold out after their page loaded.
A guest scans, the menu loads, and from that second the page is a photograph of your kitchen as it was. They browse, they talk, ten minutes pass. Behind the counter the last portion goes. Their phone still shows the dish, full colour, orderable — no system can push news onto a page it cannot see. The interesting question is what happens when they press order.
The server is the only honest gatekeeper
The order request is checked against availability at the moment it arrives, not at the moment the menu loaded. A sold-out line refuses the whole order — by name: "has just sold out — take it off to carry on". The name matters. A generic failure tells a guest the website is broken; a named one tells them exactly which line to remove and that everything else is fine.
Refuse, restore, and stay editable
After the refusal the basket must be exactly as they left it — nothing disabled, nothing spinning, the place-order button restored. We audited this end-to-end this week: flipped an item off after a guest's page had loaded and watched them try to order it five times. Every attempt refused, every attempt recovered. The one thing worse than the refusal would be a button that says "placing your order…" forever over an order that never went.
And shrink the window where you can
The refusal is the guarantee, not the experience. Item cards on the menu grey out with the word on them when the page does know; options inside a dish — the topping that ran out, not the dish itself — now carry their own off state too, greyed with "off today" where the picker was. A guest who never gets to want the thing that is gone never needs refusing at all.