A point-of-sale system for one business, many locations

One order model. Two kinds of store.

Retail scans a barcode, pays, and leaves in a minute. A restaurant tab lingers for an hour, adds courses, and splits the check three ways. Same tables, same lifecycle, different screens.

Read the docs View on GitHub

What's in the box

Four surfaces, one API, one database

Register

The till. Scanner-first for retail; menu grid, floor view, open tabs, modifiers, coursing, and split checks for food service. Cash drawer with a blind count.

Back office

The manager's side: catalog, staff and per-location roles, register settings, sales and stock reports, and a viewer for the append-only audit trail.

Desktop shell

Tauri v2 hosts the same register and adds what a browser tab cannot do: a thermal printer and a cash drawer.

API

Laravel action-class architecture. Every mutation audited, every financial record append-only, all money in integer cents.

In the store

The register and the back office

Retail register with items scanned into the cart — Retail — scan into the cart

Cash tender screen showing computed change — Cash tender with computed change

Food-service menu grid with modifiers — Food service — menu grid and modifiers

Floor view listing open tabs by table — Floor view — open tabs by table

Back-office Today landing page — Back office — the Today landing

Sales report in the back office — Sales reports, ledger-basis

Principles that shape everything

Decisions, written down first

Money is integer cents, always

One rounding primitive in one place; split payments and refunds are penny-exact by construction.

Financial records are append-only

A refund is new rows; a closed order is never mutated; last year's receipt reprints identically.

One order model

Food service is retail plus a longer open phase — proven, not assumed: the food-service milestone shipped with zero new order tables.

Config is deployed, data is administered

Engineers change config; admins change the database; nothing lives in both.

The server decides, the terminal obeys

The API says what a receipt contains and whether a drawer may open. No money decision lives where it cannot be audited.

Quick start

Running in four commands

cp .env.example .env
make dev-key          # mints an APP_KEY — paste it into .env
make dev              # full stack: Postgres, API, register, back office
make seed             # demo data — prints dev PINs and device tokens

Register at localhost:5174 · back office at localhost:5175 · API health at localhost:8000/api/v1/health. Requirements: Docker. Nothing else.