Staff POS
Quick order, phone orders, the live queue, driver dispatch, the register and open tabs — plus a builder per item type.
Nine apps, one shop.
Which app an install becomes is decided when it is built, not by a setting somebody can flip on a live terminal. A kitchen tablet is a kitchen app — a separate application with its own identity on the device, not a mode of one big app. A build naming a app the system does not recognise fails loudly at startup rather than quietly rendering the staff terminal underneath another app’s branding. The back-office apps check the signed-in person’s role on top of that, so a build reaching the wrong hands is still not a way in.
Kitchen display
The make line, oven tracking, the prep station and speed metrics. Wall-mounted, location-scoped, no bottom nav.
Driver
Assigned deliveries, navigation, proof of delivery, cash on hand, shift earnings, wearable settings.
Customer ordering
Home, menu, the pizza builder, a live order tracker addressable by order, and an account with reorder and saved addresses.
Self-serve kiosk
One linear flow with no way to get lost: attract, menu, builder, cart, payment, confirmation.
Owner & manager
Dashboard, AI insights, food cost, labour, reviews and marketing. Named for the manager who lives in it daily, not the owner who checks it weekly.
Franchise
Locations, menu authority, benchmarking, compliance and onboarding across every store.
In-store display
A pickup status board or a digital menu board — chosen when the artifact is built, because the device is nailed to a wall and nobody is going to navigate it.
Admin
Standing up a new shop, and the checks the people who audit one need to see.
Where it starts
Every order arrives somewhere different.
The channel is carried on the order itself, so the kitchen, the queue and the reports all read it from one place rather than each inferring it. Which channels a shop accepts is a setting, not a build.
Counter
Rung on the staff terminal, tagged as a counter order. Walk-in, pickup, dine-in or delivery — the order type decides what has to be captured before it can be sent anywhere.
Phone
Taken on the phone console and tagged as a phone order. It requires a name and a number before the order exists, because a phone order without a callback is a dead order.
Kiosk
Placed in-store by the guest and tagged as a kiosk order, with no staff time spent per order.
Customer web and mobile
Placed by the guest in the ordering app, against the same catalog the counter is reading — the same items, the same builder, the same 86 list.
The cook can see the channel from across the room.
Every make-line ticket carries a badge for where the order came from, with an icon and a colour per family — in-house, call, self-serve, off-premise. The badge is exhaustive over the channel list, so adding a channel and forgetting to give it a badge is a build failure rather than a blank space on a wall display. An unrecognised channel word still resolves to something a cook can read, and a shop’s allowed-channel list ignores a word it does not know rather than quietly filing it under the counter.
The state it is in
Seven lanes, named however your shop names them.
Shops do not agree on what to call things, and neither do the systems they came from. So the queue does not fix the status words in place: over sixty raw tokens from several vocabularies already resolve onto seven lanes with nothing configured, and a shop that uses its own words remaps them without a code change. Anything still unrecognised shows in the first lane rather than disappearing from the board.
-
New
Accepted and untouched. Also where an order lands if its status word is one nothing recognises — an unreadable order shows up on the queue rather than disappearing from it.
-
Making
On the make line.
-
Oven
Baking, tracked through a real deck and slot on the oven board.
-
Ready
Cut, boxed and waiting — for the counter, for the guest, or for a driver.
-
Out for delivery
With a driver.
-
Delivered
Fulfilled and terminal, whether it was handed over at the counter or at a door.
-
Cancelled
Terminal and unfulfilled. Kept distinct from delivered, because a shop that cannot tell those apart cannot read its own day.
The crossings
One order, all the way through.
1
It is rung
Wherever the order came from, the same three questions get answered: who is this for, what happens after it is rung, and which of those the shop even permits here. A delivery order will not go out without a name, a number and an address — the address is what feeds the zone, the fee, the ETA and dispatch. A dine-in order needs a table. None of that is fixed in place; a counter shop, a dining room and a delivery-only kitchen are the same code path with different settings.
2
The kitchen sees it
The make-line board reads the order feed, listens for changes, and re-reads on its own timer regardless. Both halves are deliberate: the listener makes it quick, the timer makes it certain, and a board that has stopped doing either says so on screen. The printer path subscribes to that same feed and splits it per station, so screen and paper cannot disagree — there is no second queue for them to disagree about.
3
It advances
An advance from the counter, the kitchen board or a successful kitchen print goes through one lifecycle engine. It checks that the signed-in person is permitted to make that move from where they are standing, writes it, and then reads it back. A response echoing the old status is a failure, not a success. Whether the operator is an individual, a shared kitchen login or a device-bound terminal, they resolve the same way. Some transitions are automatic and some are a person pressing a control, and which is which is a setting rather than a rule baked into the app.
4
Everyone else finds out
One status change crosses the bus once, in one shape, built and read in one place — so the producer and the consumers cannot each pick their own spelling for it. They did once: the guest tracker read a key the engine never sent, and ran BACKWARDS to "Order received" with a fresh timestamp every time the kitchen advanced, while the pickup board silently dropped every event. Nothing errored. That is why neither side names a key any more.
5
A driver closes it
Proof of delivery captures a photo and a signature, runs a vision check on the photo, uploads both, and completes the order. It also closes the delivery assignment — a separate record. Skip that second write and driver earnings query a status that never changes, and report an honest-looking, permanently wrong zero. The driver’s writes go straight to the order today rather than through the lifecycle engine, so the guest’s tracker picks the completion up on its next refresh rather than the same second. We would rather write that down than let you find it.
6
The room already knows
The pickup board and the menu board are the same order record on a wall. There is no separate signage system to keep in sync and nothing to re-enter at the end of the night.
What this is worth on a Friday.
Every one of the failures described above was found in this product and fixed in it. They are on this page because they are the failures a shop inherits from any system where each screen keeps its own copy of the order: a tracker that lies to a guest, a board that drops events, earnings that read zero, the same pie in the oven twice. One record removes the category of bug, not one instance of it.
Book a demo