One POS system that keeps every store in sync
A point-of-sale platform that unifies in-store checkout, inventory, and store-level reporting into one dependable system built for the shop floor.
Who, what, and how long
- Industry
- E-commerce & Retail
- Duration
- 22 weeks
- Cooperation model
- Dedicated team
Client name withheld under NDA. Engagement details are shown to the extent our agreement permits.
The hard problem
- 01
Staff retyped data by hand and stock counts were rarely trustworthy by end of day, making reorder decisions guesswork.
Stock was a number in one system and a different number in another, reconciled overnight, so from the moment the shop opened, both were wrong and neither knew it. Staff retyped deliveries into two places. By close of trade the counts were unreliable enough that reorder decisions were being made from the shelf instead of the screen.
We built a single POS platform with shared inventory state, a fast checkout flow tuned for busy counters, and store-level reporting that updates as sales happen.
The system we were asked to build
Registers, inventory, and reporting lived in separate tools that drifted out of sync. We built one POS platform with a shared source of truth across every store.
Twenty-two stores running registers from one vendor, a stock system from another, and a reporting spreadsheet assembled on Mondays. The three had been integrated by nightly file exchange, which worked until it didn't. The engagement was commissioned after a Christmas where the chain sold stock it didn't have in eleven stores and had to cancel the orders by hand.
Systems Integration
How the pieces fit
- 01
Modeled one inventory source shared across registers and stores
The chain had two stock figures reconciling overnight, so this step was mostly deciding which to keep. The answer was neither, since both were derived badly.
- 02
Built an offline-tolerant checkout for unreliable store networks
The register runs against a local database and treats the network as an enhancement, replaying transactions in order when the link returns.
- 03
Shipped live store reporting for managers
Managers were asked what they check on a Saturday afternoon, and the answer was three numbers on a phone behind a counter, which is what the board became.
- 04
Migrated locations in waves with zero-downtime cutover
Stores migrated in waves of four with the old system running in parallel until a full week reconciled. No store cut over on a successful test alone.
Offline-Tolerant Checkout Register
Keeps store registers ringing and processing transactions even during network outages.
The register runs entirely against IndexedDB and treats the network as an enhancement, so an outage at four on a Saturday doesn't stop the queue. Transactions are recorded locally with a monotonic sequence per register and replayed in order when the link returns; card payments fall back to the terminal's own store-and-forward. Nothing about the cashier's flow changes when connectivity drops. There's no offline mode to enter.
- IndexedDB-backed register; the network is optional
- Per-register monotonic sequence, replayed in order
- No offline mode to enter: the flow stays the same
Twenty minutes with no connection at Dorrick Park: nine sales held on the register itself, none lost, and the next cart being served exactly as it would be online.
Unified Inventory Pipeline
Dairy across six stores, counted at the register as it sells, never overnight, with the four lines that have run out somewhere, and the delta log behind one figure where a warehouse transfer sits in the same ledger as the sales.
Real-time stock synchronization across all retail stores and central warehouse.
Stock is one number per SKU per location, held server-side and pushed to every register over a subscription, so two stores can't both sell the last unit. Transfers between stores and the warehouse move through the same ledger as sales, with no separate adjustment path, which is what removed the monthly reconciliation. Counts write as deltas, never as absolute overwrites.
- One authoritative stock figure per SKU per location
- Transfers and sales share one ledger, no side path
- Deltas, never absolute overwrites
Live Store Manager Analytics
Instant reporting on hourly sales volume, top SKUs, and register performance.
Reporting reads from the same event stream the registers write to, so the hourly figure a manager sees is the sales themselves, not a nightly rollup of them. The board is built for a phone behind a counter: three numbers above the fold, top SKUs and register performance beneath, and a comparison against the same hour last week so a quiet afternoon can be read in context.
- Reads the live sale stream, never a nightly rollup
- Three headline figures above the fold on a phone
- Every figure compared against the same hour last week
The manager's board on a phone behind the counter: three figures for the hour so far, each against the same hour last week, then the top lines and the four registers that add up to the hour's takings.
Phase by phase
Phase 1: Hardware & Inventory Discovery
Store Workflow & Stock Audit
Audited register hardware, barcode scanners, and inventory drift across twenty-two stores.
- Hardware Discovery Report
- Inventory Architecture Spec
- POS Migration Plan
Phase 2: Offline-Tolerant Register Build
IndexedDB Local Store Persistence
Engineered a local IndexedDB persistence layer so registers operate continuously through network dropouts, syncing once reconnected.
- Offline Register Engine
- Local DB Sync Pipeline
- Barcode Scanner Connector
Phase 3: Central Inventory & Reporting
Unified Stock API & Manager Dashboard
Engineered unified inventory APIs and real-time store manager reporting dashboards for stock level and sale analytics.
- Central Inventory API
- Real-Time Manager Dashboard
- Audit Trail Logging
Phase 4: Multi-Store Wave Cutover
Zero-Downtime Deployment & Training
Migrated stores in planned waves of four with zero downtime, training store leads on new checkout and inventory workflows.
- Wave Cutover Schedule
- Store Staff Training Modules
- Production Sign-off
Cashing up in six minutes instead of thirty: the drawer counted note by note against what the ledger already knew, balanced to the penny, with the card total taken straight from the terminal.
What it carries now
99.2%
Stock accuracy
+35%
Checkout speed
−80%
End-of-day reconciliation
Stock accuracy is measured against physical cycle counts across all twenty-two stores over the first quarter, not against the system's own figures. Checkout speed is median time from first scan to payment complete, sampled at comparable trading hours. Reconciliation time is the chain's own end-of-day labor figure per store.
Client name withheld under NDA. Figures are approximate, drawn from the engagement’s own reporting.
What the architecture settled
Shared single-source inventory brought store stock accuracy up to 99.2%.
Accuracy came from removing the second number, not from syncing it better: two systems reconciling nightly are wrong for the whole trading day by construction.
Optimized counter checkout interface increased checkout speed by +35%.
The checkout gain was mostly the network: a register that never waits on a round trip is faster at the counter than one that usually doesn't.
Automated end-of-day reconciliation reduced nightly register auditing time by 80%.
End-of-day reconciliation collapsed because there was nothing left to reconcile. The ledger the register writes is the ledger the report reads.
How the work was run
- 01
A cross-functional team of 5 worked on a dedicated team basis over 22 weeks, covering Platform engineering, Inventory sync, Reporting. We ran a weekly demo and kept a shared board open to check at any time. An in-house team took over day-to-day operation before the engagement ended, with handover built into the last phase.
A dedicated team ran alongside the chain's own operations staff for the full twenty-two weeks, with a store manager in every review, held every two weeks. Migration went in waves of four stores with the old system live in parallel until each wave's figures reconciled for a full week. Nothing was cut over on the strength of a successful test.
Pull the cable on a till
The queue keeps moving. The book catches up, in order.
Three registers at Dorrick Park writing into one shared ledger, and Till 2 has already lost its connection. Ring up sales on any register, switch a connection off and on, and watch held sales replay in sequence while the stock figure moves on every register. Switch registers with the tabs, or the arrow keys once one is focused.
Ring up a sale
Held on this till2 waiting for the link
- #4471 Oat
- #4472 Steel
Stock as each till sees it
| Line | T1 | T2 | T3 | Book |
|---|---|---|---|---|
| Oat milk 1 L | 22 | 23 | 22 | 22 |
| Sourdough loaf | 11 | 12 | 11 | 11 |
| Steel flask 500 ml | 6 | 5 | 6 | 6 |
Amber is a register counting sales the book hasn't had yet.
The shared book3 writes
- T1 #7214Oat milk 1 L −1
- T3 #3028Sourdough loaf −1
- T1 #7213Oat milk 1 L −1
Why nothing is lost: the register writes every sale to its own database first and treats the network as an enhancement, so there's no offline mode to enter. Goods, stock levels and the replay pacing here are illustrative.
From one scan to the same number on every register
The ledger the register writes is the ledger the report reads. There's no second stock figure to reconcile overnight, and no nightly file exchange between a register, a stock system and a spreadsheet.
- 01 · TriggerA scan at the tillThe register runs entirely against IndexedDB, so a sale is recorded on the register before the network is asked for anything.
- 02 · QueuePer-register sequenceEach register numbers its transactions monotonically and replays them in order when the link returns. Card payments fall back to the terminal's store-and-forward.
- 03 · EngineUnified stock APISales, refunds, counts and transfers between stores and the warehouse move through one path, written as deltas and never as absolute overwrites.
- 04 · StateOne ledger in PostgreSQLOne authoritative stock figure per SKU per location, held server-side, so two stores can't both sell the last unit.
- 05 · DeliverySubscriptions to registers and phonesEvery register has the figure pushed over a subscription, and the manager's board reads the same event stream, with no nightly rollup.
What a Saturday afternoon can throw at it
Outages, oversells & cutover
A dropped link doesn't stop the queue
The register records every sale locally with its own sequence number and replays them in order when the connection returns. Card payments use the terminal's store-and-forward, and there's no offline mode for staff to enter.
Two stores can't sell the same last unit
Stock is one figure per SKU per location, held server-side and pushed to every register. Transfers go through the same ledger as sales, and counts write as deltas, so nothing overwrites anything else.
No store cut over on a passing test
Stores moved in waves of four with the old system running in parallel, and nothing was cut over until that wave's figures had reconciled for a full week.
Registers, stock and reporting that disagree by lunchtime? Scope your build in 3 minutes.
Scope your buildNearby engagements
Data & AnalyticsA checkout that stopped losing sales to a 6-second load
Profiling found the real bottleneck behind a slow checkout (an N+1 query and an oversized bundle) and tuned both, with before-and-after metrics locked in as a baseline against future regressions.
E-commerce & Retail · 5 weeks
Web PlatformsA reader people finish, and a library that remembers where they stopped
A reading platform for a comics catalog: a browse surface people can actually navigate, a reader that gets out of the way, and a history that puts everyone back on the page they left.
E-commerce & Retail · 18 weeks
Web PlatformsOne number, a whole handset, and a database that keeps up with 125 brands
A metered IMEI lookup service that turns fifteen digits into a device, its specifications and its status. It's sold three ways to three audiences and backed by a device database that maintains itself.
Consumer Electronics · 22 weeks
Let's talk
Running a large platform, shaping a first MVP, or getting a product ready for a funding round? Tell us where you are. We'll shape the process around it, and stay with you after launch.
