Resto runs front-of-house and back-of-house for sit-down restaurants — QR ordering, kitchen display, waitlist, inventory, payments and analytics, all from a browser. Diners scan the code fixed to their table and order from their own phone. No app to install, no account to create.
And nothing reaches the kitchen until a member of staff confirms it, standing at the table.
Step 1
The code is specific to that table. The menu opens immediately — prices, photos, ingredients, allergens, dietary filters, search.
Step 2
Everyone at the table adds to the same order, with modifiers and cooking instructions in their own words.
Step 3
The diner's phone shows a confirmation code. Staff scan it at the table, adjust quantities, catch anything sold out, and confirm.
Step 4
The ticket lands on the kitchen display, routed to the right station, with allergy notes impossible to miss.
Step 5
Diners track status live. Later rounds go through exactly the same confirmation, all meal long.
Step 6
Pay from the phone, split it across the table, or hand a card to a server. Cash works exactly as it always did.
Allergens as structured data, with "contains" kept distinct from "may contain", because that difference is a legal one. Dietary tags, ingredients, calories, spice level. Edit against a draft, publish when it is right, roll back in one click.
Tickets grouped by station, ageing from white through amber to red, all-day counts, and one-tap 86 that reaches every diner's phone in about a second. It keeps working when the network drops and reconciles when it returns.
When every table is full, a code at the door puts guests on the waitlist with a live position and a wait estimate drawn from your own table-turn history, not a guess.
Card and wallet from the diner's phone, or card and cash at the table. If a payment provider goes down, the meal still ends properly — the tender is recorded and service continues.
Stock that depletes as dishes sell, roles and permissions granular enough for a real floor, and reports on sales, ticket times, table turns and what your guests actually say.
Multi-currency, multi-timezone, multi-language and multi-tax-regime by design rather than by retrofit. Money is stored as whole minor units and never as a floating-point number, so a bill adds up the same way an accountant would add it.
So they should not get the same software. You answer one question when you set up, and you get the modules that match how you actually work — a café gets a short settings page and a handful of screens, a fine-dining room gets courses, coursing and split billing. Turn things on later as you grow; nothing is deleted when you turn something off.