One system from QR code to profit report

What was the problem?

Order entry slow enough to build a queue during a rush, a kitchen that started cooking before payment confirmed and absorbed every mistake as wasted food, and customers interrupting staff to ask where their order was. Stock and expenses were reconstructed after closing rather than captured during service.

What made it hard

What we built

A full-stack POS built end to end: sub-10-second order booking, a payment-gated kitchen flow so orders reach the kitchen only after payment, real-time customer notifications through placed, preparing and ready for pickup, automated invoicing, inventory, expense tracking, reports, role-based user management, custom menus and a kitchen module.

What it does

• QR-code customer ordering with no login or app

• Live kitchen queue position for the customer

• Returning-customer recognition by phone number

• Sub-15-second counter billing

• Quick row of five most-ordered items from real history

• Audio-haptic bill confirmation

• Kitchen board with role-scoped ticket view

• Eight-tile owner dashboard with live profit

• Repeat-customer table with lifetime spend

• Searchable invoice ledger with CSV export

• Audit-trailed invoice editing with money lock on payment

• Menu, add-on, inventory and expense management

• Owner-managed staff accounts and roles

• Branded A4 PDF and thermal invoicing

• Star ratings tied to specific invoices

• Command palette search across orders, menu and inventory

• Installable PWA with platform-aware install flow

Engineering decisions

Choices that could have gone another way, and what each one bought.

1. 1

   Invoice numbers that cannot collide

   Bill numbering is implemented as an atomic Firestore transaction — the counter read, the increment and the order write happen as a single indivisible operation, on the client for counter billing and through the Admin SDK for public QR orders, sharing one identical path scheme.

   Why it matters. Two cashiers and a QR-code customer can hit confirm in the same millisecond and still get PT-0041, PT-0042 and PT-0043. It also costs one round trip instead of two, so billing feels instant. Bill numbering is the one thing a restaurant cannot get wrong.

2. 2

   A financial-integrity rule built into the workflow

   Money fields lock the moment an order is marked paid. Only the customer name and phone stay editable afterwards, and every edit is stamped with an author and a timestamp, displayed alongside the invoice number.

   Why it matters. That is the difference between a billing app and an app an accountant will accept.

3. 3

   A date-partitioned ledger designed for year five

   Orders are stored on a hierarchical path — business, year, month, date, orders — so a single day's business can be read without touching a record from any other day, while collection-group indexes still allow instant search across all time.

   Why it matters. The app is intended to stay exactly as fast in its third year as on day one, rather than degrading as history accumulates.

4. 4

   Two authentication systems, bridged invisibly

   Staff sign in with email and password against a bcrypt-hashed directory through NextAuth. That session is exchanged server-side for a short-lived Firebase custom token, which is what actually authorises database reads and writes.

   Why it matters. One login for the user, proper database-level security rules underneath, and an owner who can add and remove staff without ever touching the Firebase console.

5. 5

   A service worker written for a financial app, not a blog

   Only content-hashed static assets are cached — never an API response, never a page, never anything user-specific — and the worker is versioned so a new deployment cleanly invalidates the old cache.

   Why it matters. A POS that serves a stale order total is worse than a POS that is offline.

6. 6

   Role-based access enforced in three layers

   A central route-to-role map drives navigation gating, client routing guards and server-side API checks, with Firestore rules scoping every read and write to the owning business. Typing a URL you are not allowed to reach redirects you to your own home screen.

   Why it matters. A cook sees the kitchen board and nothing else — no prices, no customer data, no billing — enforced at every layer rather than hidden in the interface.

7. 7

   Designed for the counter, not the desk

   Fifteen-second billing flows, thumb-reachable controls, a Quick row computed from real order history, a command palette searching orders, menu and inventory at once, and audio-haptic confirmation — a three-note chime plus vibration — so staff know a bill saved without looking at the screen.

   Why it matters. During a rush, staff are not looking at the screen. The system has to confirm through sound and touch.

Technical detail

Collapsed by default. Open whichever part you are evaluating.

Before and after

The build, by the numbers

What was built, at what scale. These describe the system's size, not its business results.

role-specific surfaces

4role-specific surfacesCustomer, reception, kitchen and owner — one shared live data model

enforcement layers for access control

3enforcement layers for access controlNavigation, client routing and server-side API checks

live dashboard tiles

8live dashboard tilesIncluding profit computed live from sales less expenses

per-terminal licence cost

0per-terminal licence costRuns in a browser on devices the restaurant already owns

What changed as a result?

Orders booked in under 10 seconds. The payment-first kitchen queue eliminates unpaid and incorrect orders, and customers stay informed in real time until pickup — a fully automated shop-floor system.

• Order booked to invoice in under 10 seconds
• Kitchen queue gated on payment, so unpaid orders cannot reach the line
• Customers notified automatically at each stage, removing status interruptions

What we can evidence

Why does this matter in restaurants & food service?

Restaurant software is the system that takes an order, bills it, tells the kitchen and records what it cost you — and it is judged at the counter during a rush, not in a demo. If booking an order takes thirty seconds, the queue builds and staff work around the system instead of through it. We built the Pizza Theory POS end to end.

• Order entry slow enough to build a queue

  Every extra second per order compounds across a dinner rush. The Pizza Theory POS books an order in under ten seconds, which is the difference between the system helping and the system being bypassed.

• Unpaid and incorrect orders reaching the kitchen

  A kitchen that starts cooking before payment confirms absorbs every mistake as wasted food. A payment-gated queue means an order only reaches the kitchen once it is paid for.

• Customers asking staff where their order is

  Every status question interrupts someone working. Real-time notifications through placed, preparing and ready-for-pickup remove almost all of those interruptions.

• Stock and expenses reconciled after closing

  Counting stock and totting up expenses at the end of a shift is where margin quietly disappears. Inventory and expense tracking inside the POS make the numbers a by-product of service.

More on what we build for restaurants & food service →

See it running