What building an offline-first POS taught us about reliability.

When we built a point-of-sale system for a retail store, the requirement that shaped everything wasn't a feature. It was a sentence: "The counter can never stop." Not when the internet dies, not when the power flickers, not when a cashier presses the wrong key at rush hour. Here's what designing for that sentence taught us — and why the lessons apply far beyond retail.

Lesson 1: Offline isn't a fallback, it's the default

Most "offline support" is a cache bolted onto a cloud app — it degrades gracefully, then quietly loses things. We inverted it: the POS runs entirely on the shop's machine, and the internet is the optional extra. Sales, stock and reports live locally; nothing a cashier does ever waits on a connection.

The reliability win is psychological too. Staff trust a tool that never shows a spinner. Trust means they use it for everything, and the data stays complete.

Lesson 2: Backups only count if restores are boring

Every system claims to back up. The real question: has anyone ever restored one, under stress, on a Tuesday? We made backups automatic and — more importantly — made restoring a two-click, five-minute routine we actually rehearsed with the owner. A backup you've never restored is a hope, not a plan.

Lesson 3: The keyboard is faster than the mouse — always

At a busy counter, every reach for the mouse costs seconds, and seconds cost queues. Every screen in the POS is fully keyboard-operable: Enter advances fields, shortcuts fire the common actions, and a whole sale can flow without a single click. Data-entry-heavy software — clinics, schools, warehouses — deserves the same respect.

Lesson 4: Build for the least technical person in the room

The system installs from one click and starts like any desktop app. No server setup, no config files, no "call the IT guy". If your software needs an engineer present to survive, it isn't finished. Simple packaging is a reliability feature — it removes the most failure-prone component: complicated setup.

Lesson 5: Reports nobody reads are decoration

We shipped three reports, not thirty: today's sales, today's profit, low stock. The owner checks them every evening because they answer the questions he actually asks. Start with the questions, work backwards to the report — never the other way.

Reliability isn't a server metric. It's whether the person at the counter trusts the tool at 7pm on the busiest day of the month.

Borrow these, whatever you're building

• Decide what must never stop, and design outward from there.
• Rehearse recovery, don't just schedule backups.
• Count the clicks in your most-repeated task — then remove half.
• Make installation and updates boring.
• Ship fewer reports; answer real questions.

Building something where "it can never stop" applies — a counter, a clinic desk, a booking line? That's our favorite kind of brief.