Local-first transaction capture
A sale is recorded on-device the instant it happens, connection or not.

A merchant-facing payments app rebuilt offline-first, so a sale can be captured and settled later instead of stalling without signal.
Start a Project
Merchants sell from markets, delivery routes and basement pop-ups — exactly where the old app's server-dependent design left a cashier staring at a spinner mid-sale. A payments app that assumes a signal it never had isn't a payments app in most of the places it's actually used.
We rebuilt the core sale flow to assume no connection by default, not as a fallback mode bolted on afterward. Settlement was redesigned as a background concern the merchant never waits on, so the app's happy path and its offline path are the same path.
An offline-first payments app with local-first transaction capture, a conflict-resolved settlement layer that reconciles once signal returns, and a merchant dashboard that reflects sales status without waiting on a connection.


A sale is recorded on-device the instant it happens, connection or not.
Reconciles automatically once signal returns, no manual review needed.
Sales status reflects reality without waiting on a round trip.
Every unsent sale sits in an ordered queue, never silently dropped.
A merchant's local sales record is encrypted at rest, not just in transit.
A merchant always knows whether a sale has settled or is still queued.


The client-side architecture and interface layer shipped for this engagement.

Services, APIs, and business logic running the system end to end.

Datastores and pipelines chosen for this engagement's consistency and throughput needs.

Deployment, orchestration, and delivery tooling running the platform in production.
Resolving conflicts when a terminal settles twice
Two devices could capture the same sale before either reconnected. Every transaction carries a device-scoped idempotency key, so settlement can safely retry without ever double-charging a customer.
Keeping the local ledger consistent after days offline
A market vendor might not reconnect for a week. The sync protocol replays queued transactions in causal order and rejects any that conflict with a server-side state the device hasn't seen yet, rather than blindly overwriting.
Background sync within a mobile battery budget
Aggressive background sync would have drained the merchant's phone by midday. Sync batches and backs off based on both connectivity quality and queue size, so it never runs more than it needs to.
1 week
Shadowed merchants selling from a market stall and a delivery route with no reliable signal.
2 weeks
Offline-first sync protocol designed before a single screen was built.
2 weeks
Sale flow designed to look identical whether or not a connection was present.
6 weeks
Local-first capture and the settlement layer built together from the first commit.
2 weeks
Field-tested across real dead zones, not simulated airplane mode.
1 week
Rolled out to a pilot group of markets before the wider merchant base.

“Our vendors stopped asking for a signal before they'd sell. The app just doesn't need one anymore.”
Ben Okafor · Operations Manager · Kestrel




Technical briefingNot a sales desk