One code on the table. Every kitchen on it.
The food-hall QR problem is not the menu — it is what happens when one guest orders from three kitchens at once. That is the case this product was built around.
One basket, one payment, no arguments
A guest scans one code, orders tacos from one kitchen and a drink from another, and pays once. Underneath, that becomes one ordinary order per kitchen — so every ticket, report, refund and stock movement stays per business, and settlement is correct because of the shape, not because somebody was careful with a spreadsheet.
Each kitchen’s ticket lands on its own pass
The birria kitchen sees the tacos, the bar sees the drink, each with its own timers and its own collection call. A guest is never waiting on the slowest kitchen to hear about the fastest.
Meal deals only a hall can sell
A main from one counter and a drink from another for one price — priced as one deal to the guest, split fairly between the two businesses underneath. General-purpose systems do not describe this; it is a first-class thing here.
The hall page is the shop window
One address lists every kitchen with its own name, photos and menu — and a kitchen that pauses stops taking orders without stopping the hall.
The venue-agnostic page for this pillar: QR ordering → · everything for this venue type: Food halls →
More for Food halls
Free to use.
Everything on this page is in the product now — and it costs a food hall nothing to run.