QR ordering, a display that glows when food is ready, a register that keeps working when the Wi‑Fi doesn't, and an end‑of‑day close that balances itself. Built for restaurants that run nights — not demos.
2×Lamb Mandi
extra rice · hot
3×Chicken Shawarma
garlic · no pickles
1×Mixed Grill
rare steak
The wedge
We didn't bolt a POS onto a menu app. Ordering, cooking, paying and closing are a single pipeline — so a ticket fired at a table is the same object the kitchen bumps, the cashier settles, and the EOD reconciles.
Scan → order → fire → plate → pay → close. One order id travels the whole night; nothing is re-keyed, nothing is lost between the table and the pass.
Guest scans table QR
anon order, source=qr_code
Ticket hits the KDS
realtime, with a timer
Cashier settles
split cash / card / wallet
EOD balances itself
payments vs orders, logged
Friday 9pm, the router dies. The register keeps opening tickets, printing and taking cash on a local queue, then syncs the moment service comes back. Order ids are minted client‑side, so nothing collides.
Sell a mandi, deduct its rice, lamb and ghee in base units. Sacks convert to grams, bottles to millilitres, and spoilage gets logged — so theoretical stock finally matches the shelf, and managers trust the numbers.
The kitchen call pings the floor shell the instant a pass light turns green. WebSockets are reserved for the three screens that need them — KDS, waiter fire, the bell — while dashboards poll, so tenant #20 doesn't inherit a connection bill.
Six seats at the table
No email soup, no shared logins. Each role lands on exactly the screens it needs — and Row Level Security makes sure a cashier's token can't even see another kitchen's data.
Own tenant · everything
Sees every screen, edits the public site and team, owns the close.
Routes to
Security you don't think about
CloudKitch is multi‑tenant from the first row. Every query a staff member runs is filtered by their own restaurant — enforced by Row Level Security, the last line of defence when everything else fails.
Postgres is the bouncer
Tenant boundaries live in the database, not in your UI. Even a frontend bug can't cross kitchens.
Anon only where it's public
Anonymous tokens can read an active menu and drop a QR order or a demo lead — nothing else.
Service role stays server-side
The master key never ships to a browser. Onboarding and the print daemon are the only holders.
create policy "tenant_data_all"
on public.orders
for all
using (
restaurant_id = get_user_restaurant_id()
or is_platform_admin()
);
-- a cashier's token can only ever see
-- orders where restaurant_id == theirs.
-- cross-tenant reads return zero rows,
-- at the database, before app code runs.Live sandbox
Fire an order and watch it land on the pass. Bump it through cooking to ready to served. This is the real interaction model of the KDS — running right here, in your browser.
simulated — nothing leaves this page
2×Lamb Mandi
COOKING1×Kunafa
READYBook a demo
Tell us about your room and we'll set up a sandbox kitchen with your menu, then walk a full service together — fire, pass, pay, close. Thirty minutes, no slides.