Till

A point-of-sale system is judged in unglamorous moments: a connection dropping mid-payment, a drawer that won't balance, a refund that needs approval during a rush. I started building Till to understand those moments from the foundation up — and it became the education in scale no smaller project could have given me.

What it is

A network of checkout terminals connected to a central server. Terminals handle sales, payments, receipts, returns, and cash management, and can run entirely on their own or stay in sync with the server — catching up automatically when the connection returns. The server holds the product catalog and employee data, collects reports from every location, and is managed through a desktop app. The warehouse side covers stock, corrections, and simple production flows, and a set of hardware emulators lets the whole system be exercised without any physical equipment.

1 / 6

What it taught me

• Offline-first is a data-model decision, not a feature. Keeping a terminal alive when the network disappears means designing how state reconciles from the very first table. It was never something I could retrofit later.
• Emulators are testability. With no real scanners, printers, or fiscal devices on hand, I built software versions of them — and the entire workflow could suddenly run end to end, any time.
• Money teaches restraint. Supervisor approvals, lockouts after repeated failures, audit logs with anomaly alerts — none of it is exciting, and all of it matters.
• Touch is its own design language. A screen someone uses while talking to a customer is a different discipline than a screen they sit down at.
• Scope is the real boss. A POS system is dozens of subsystems wearing one name. Breaking "big" into versions was the only way forward.

Where it stands

In development — the core works end to end, and the remaining work is depth: more workflows, more edge cases, more polish.