Run a café, a restaurant or a gaming lounge from one system.

The backend is NestJS on PostgreSQL, with Prisma as the data layer and Socket.IO carrying live updates. The waiter, cashier, kitchen and guest apps are React Native through Expo; the manager dashboard and the guest ordering page are React in the browser. All of them draw from one shared set of domain rules, design tokens and translations, so a price rule, a colour or a phrase is written down once and not seven times.

Isolation is enforced by PostgreSQL itself, not by a filter in application code. Tenant-scoped tables carry row-level-security policies keyed on a per-transaction setting, and a database-client extension binds that setting before any query runs — so a query that forgets which venue it belongs to returns nothing at all rather than somebody else’s rows. Above that, a scope guard narrows each member of staff to the branches, floors, areas, tables and resources they actually cover, so a supervisor sees one floor, a manager sees one branch, and the owner sees the group.

A check can be split by item, into equal shares, or by percentage. Checks can also be merged, charges moved from one to another, and a single check settled by more than one tender — cash, card, wallet, bank transfer or voucher — walking from open to partly paid to paid as each one lands. Discounts, voids, refunds and tips each carry a reason, and past a threshold a manager’s approval. Money is held as a decimal from end to end and never as a floating-point number.

Order, with nothing to download. Scanning the code on the table tells the session which branch and which table it belongs to, then opens the menu in the guest’s own language: a cart, modifiers, item-by-item status as the kitchen works through the order, and a way to call a waiter, ask for water or ask for the bill without catching anyone’s eye. The Wi-Fi credentials are on the same screen. Settlement happens at the cashier, where the check can be split and taken in more than one tender.

From the spreadsheet you already keep it in. The importer reads a workbook, matches English or Arabic column headings, folds per-language columns into real translation rows and a sheet of sizes into variants of one item, and shows you exactly what it understood before a single row is written. Run it again to update, and in replace mode it retires the products you left out instead of deleting them, so last month’s orders and stock movements still point at something real. The rest of the setup — branches, areas, staff, roles and the floor plan itself — happens in the dashboard against a nine-step checklist that reads the account and tells you what is genuinely outstanding rather than what someone forgot to tick.

As many as the estate has. One deployment holds many venues; a venue holds branches, a branch holds floors, a floor holds areas, and an area holds tables and timed resources — and nothing caps the number of any of them. Each branch carries its own timezone, currency and address, so a group with a coastal branch and a city one is a single account rather than two systems that have to be reconciled by hand. What narrows is what a person sees rather than what the system holds: a role answers what you may do and a scope answers where, from the whole group down to one table on one floor.

Down to a single table, and under conditions you set. A role answers what a person may do, a scope answers where — the group, a branch, a floor, an area, a table or one resource — and a policy answers under which conditions, which is where a discount ceiling, a void after the kitchen has already started, a price override and a stock adjustment live. An action that trips a policy is either refused outright or parked as an approval for someone who holds the permission to resolve, so a supervisor is asked rather than a guest being turned away at the counter with no explanation. Every sensitive action writes an audit row, and the trail is read-only by design.

Yes, from the recipe rather than from an estimate. Raw materials hold a moving-average cost per stock unit, a recipe is versioned and each version is immutable — so a sale from March keeps pointing at the recipe that was active in March — and cost of goods for a sale is summed from the consumption movements that sale caused rather than recomputed from this week’s supplier prices, which is the difference between a margin figure and a guess. Waste is written off with a reason against the same ledger, and each raw material carries a reorder point and a reorder quantity, so the stock room is warned before the kitchen is.

The data is the venue’s. Report rows export as CSV for anyone whose role carries the export permission, a check prints or saves as a PDF straight from the browser, and a full copy of the account can be taken from the PostgreSQL database it lives in — there is no proprietary format standing between a venue and its own sales history. What a person may export is governed the same way everything else is: by the permission on their role, so the export is a deliberate act by somebody entitled to make it rather than a button on every screen.

The account is archived, and nothing is destroyed. Offboarding marks it archived with the date and lifts it out of the operator’s working list rather than out of the database, and the same is true of a customer, a product, a branch or a member of staff removed in the ordinary course of a week — each carries a removed-on date, because orders and stock movements still point at them and a report that silently loses last year is worse than one that is honest about it. History stays readable and stays the venue’s. A deletion date is something to agree in writing, so disposal is a decision somebody makes rather than one a background job makes for them.