Veltacode

Build a POS that survives the internet

A five-part build-along: a point-of-sale system that keeps selling when the connection drops, reconciles stock across tills without conflicts, and is honest about which payments can be verified offline.

5 parts

  1. 01Offline-first POS, part 1: why the network cannot be on the critical path

    Most POS demos assume a working connection. Real shops do not have one. The architecture that keeps a till selling through an outage — and why offline-first is an ordering decision, not a feature.

    10 Aug 2026 · 5 min read

  2. 02Offline-first POS, part 2: never store a stock level

    The schema decision that makes offline sync work: store append-only stock movements and derive the level, so two tills syncing in either order reach the same answer.

    10 Aug 2026 · 4 min read

  3. 03Offline-first POS, part 3: selling with the router unplugged

    Writing a sale to IndexedDB, printing a receipt with no server, and an outbox that survives a browser crash mid-sale — plus why the stock number should say '~12'.

    10 Aug 2026 · 3 min read

  4. 04Offline-first POS, part 4: idempotent sync and the last-item problem

    Accepting a batch that contains sales you already have, per-sale transactions so one bad record cannot poison a batch, and what to do when two tills sold the same last item.

    10 Aug 2026 · 3 min read

  5. 05Offline-first POS, part 5: KHQR when there is no connection

    A KHQR payment cannot be verified offline. Generating the QR locally, the pending-verification state machine, offline payment limits, and handling USD and riel in one drawer.

    10 Aug 2026 · 5 min read