The platform
Twenty-two modules that were built as one system.
Not a suite of products that learned to talk to each other. One database, one login and one permission matrix, divided into 21 licensable modules plus the kiosk surface — so you switch on what the restaurant runs today and the rest waits behind the same login.
22 modules·6 categories·21 licensable·one schema per restaurant
How to read this page
The whole product, on one page.
Six categories. Every entry links to its own page, and carries the object it owns — the quickest way to see where a piece of the restaurant lives.
Core
Order ManagementEvery channel, one queueOwns the order Menu ManagementItems, add-ons, availabilityOwns items and prices Billing & InvoicingGST bills, splits, receiptsOwns the bill and payments Table ManagementLive floor, status, movesOwns tables and QR codes QR Self-OrderDiners order from phoneOwns the diner session InventoryStock that deducts itselfOwns stock, POs, GRNsOperations
Kitchen Display (KDS)Live tickets, no refreshOwns the ticket and the bump ReservationsBookings, slots, auto-seatOwns the booking SuppliersPurchase orders and GRNOwns the supplier and its rates DeliveryRiders, tracking, settlementOwns the run and the rider AnalyticsRevenue, items, occupancyOwns nothing — reads everything Customer-Facing DisplaySecond screen at counterOwns nothing — mirrors the order ExpensesDaily spend, categories, receiptsOwns the expense entryStaff
Staff ProfilesPeople, roles, permissionsOwns the staff member Shifts & AttendanceRosters, clock-in, leaveOwns shifts and attendance Waiter AppTake orders at tableOwns nothing — it is a surface PayrollWages, advances, payoutsOwns the pay runEvery object has exactly one owner.
The question buyers actually ask is whether these modules overlap. They don't: each one owns a defined set of objects and reads the rest. Billing never edits an order's items; analytics never holds a figure of its own.
Core
- Orders The order — its items, add-ons, notes, channel and status. Also the table or delivery address it belongs to, and every status change with who made it. Reads prices from Menu and occupancy from Tables. Open module
- Menu Categories, items, variants, add-on groups, prices, tax category and availability. Also the recipe that ties a dish to its ingredients. Nothing else writes a price. Open module
- Billing The bill, its tax lines and round-off, every payment against it, refunds and the receipt. Reads the order for its lines; it never edits them. Tax is computed on the post-discount taxable value. Open module
- Tables Sections and floors, tables and seats, occupancy state, table QR tokens and surcharges. A table is busy because an order says so — the state is derived, not typed in. Open module
- QR self-order The scanned table session, the diner's cart and the tracking token. On checkout it writes into Orders. It holds no menu and no price of its own. Open module
- Inventory Ingredients and units, stock on hand, purchase orders, GRNs, wastage and stock-takes with their variance. Reads recipes from Menu so a confirmed order deducts itself. Open module
Operations
- Kitchen display The ticket, its station routing and the bump event. The ticket is a view of an order; bumping it writes the status back onto that order and pushes it to every other surface. Open module
- Reservations The booking — party, slot, status and contact — and the link to a table once it is seated. Reads Tables for availability, Customers for who is booking. Open module
- Suppliers The supplier, its contacts, terms and the item rates a purchase order is priced from. The PO itself belongs to Inventory; the rate on its line comes from here. Open module
- Delivery The run — rider, pickup and drop, live status, proof of delivery and the cash collected at the door. The order and the bill stay where they are; the run points at them. Open module
- Analytics Nothing. It owns no figure at all. It reads settled bills, orders, stock movements, expenses and attendance. There is no reporting copy of the data to drift out of step with the till. Open module
- Customer display Nothing. It is a read-only render. The second screen mirrors the order being rung up, line by line, and is pushed the same events the cashier's screen gets. Open module
- Expenses The expense entry, its category, any recurring schedule and the attached receipt. Reads Suppliers for the payee. Feeds the day's net figure alongside sales. Open module
Staff
- Staff profiles The staff member — contact and employment details, the login, and the array of role bundles they hold. Permissions themselves are never stored on the person; they are computed from the bundles at sign-in. Open module
- Shifts & attendance The roster, shift assignments, clock-in and clock-out records, and leave. Reads the staff record; writes the hours Payroll later pays against. Open module
- Waiter app Nothing of its own — it is a surface, not a store. Tables, orders and billing rendered for a phone in an apron pocket, held to that waiter's own permissions. Open module
- Payroll The pay period, the wage calculation, advances and payouts. Reads hours from Shifts & Attendance and the wage terms from the staff record. Open module
CRM & growth
- Customers The customer — phone, addresses, segment membership and feedback. Order count and lifetime spend are derived from their bills, not typed in, so they cannot drift. Open module
- Loyalty & offers The points ledger, tiers, offers and their caps, and referrals. An offer writes a discount onto the order; the money itself stays with Orders and Billing. Open module
Notifications, add-ons & surfaces
- WhatsApp Message templates, the send log against each customer, and credits. It sends nothing on its own — orders, reservations and delivery runs trigger it, from the restaurant's own number. Open module
- Customer portal The public storefront, its pages and the diner's web session. A web order lands in the same queue as a table order, tagged with the channel it came from. Open module
- Self-order kiosk The kiosk session, its upsell prompts and the hand-off to self checkout. Same menu, same prices, same order table as the counter. Open module
One owner per object·everything else reads·no sync, no reconciliation
Six things every module gets, whichever ones you run.
These are not features of a particular module. They are the floor the whole platform stands on, so a module you turn on next year behaves exactly like the ones you started with.
One login
A staff member signs in once and sees every module the restaurant has, filtered by what they are allowed to touch. No per-module account, no second password.
One permission matrix
106 atomic permissions across 11 role bundles. A role is a named bundle, not a rank; staff hold several and effective access is the union. The code checks the permission, never the role name.
One tenant schema
Your menu, orders, staff and bills live in a PostgreSQL schema of your own. There is no shared table to leak across and no tenant id to forget in a WHERE clause.
One audit trail
Money and status changes are recorded with who did it and when — a discount removed, a bill voided, an order's total edited. The same trail whichever module made the change.
The same WebSocket
The kitchen board, the live order list and the floor plan are pushed, not polled. A change made on one surface reaches the others in the same second, with no refresh button to press.
The same p95 budget
List endpoints inside 200 ms, detail inside 100 ms, pages capped and indexed on every hot path. A newer module is held to the same number as the oldest one.
A plan is a set of modules.
Modules are gated per plan. A plan names which of them the restaurant has and the capacity limits that come with them — and the gate is enforced in the API, not just hidden in the menu.
- A module outside your plan isn't in the navigation, and the API refuses it too
- Adding one is a plan change — same login, same data, nothing to reinstall
- Turning a module off never deletes what it wrote; the history stays on the order
- Every module still obeys the permission matrix — the plan says what the restaurant has, roles say who may touch it
What a plan actually decides
See it running on your menu.
We set the restaurant up with you — menu, tables, staff and printers — rather than handing over a login and wishing you luck.