Custom business system
Offline-first van sales for FMCG distribution
Van sales and distribution for an FMCG operation — reps sell, invoice, and settle from a phone on the route, offline, and the back office sees it when they reconnect.
A field sales and distribution system for a fast-moving consumer goods operation: sales representatives visit outlets on a route, take or fulfil orders from van stock, invoice on the spot, collect payment, and settle at the end of the day.
Delivered for a client in FMCG distribution. Named details, figures, and outcomes are omitted — no permission to publish them has been given. What follows is the engineering, which is mine to describe.
The problem it solves
Before a system exists, this runs on paper. A rep leaves the depot with stock and a route list, writes invoices by hand, collects cash, and reconciles at the depot in the evening. The back office finds out what was sold roughly a day late, inventory is a best guess until the count, and any dispute about what was delivered comes down to whether someone can find the carbon copy.
The cost isn’t only the admin. It is that nobody can answer basic questions — which outlets were actually visited, which products are moving in which territory, how much cash is outstanding with which rep — while there is still time to act on the answer.
What makes it hard
The defining constraint is that the phone in the rep’s hand is often the source of truth, and it is frequently offline.
- Offline-first is the architecture, not a feature. A rep in a warehouse basement or a rural route has no signal. The app has to work fully offline — full catalogue, pricing, customer balances, stock on the van — and sync when it can. That means the device holds real state, which means conflicts are guaranteed and have to be resolved by rules the business agrees with, not by last-write-wins.
- Van stock is inventory with legs. Every van is effectively a moving warehouse. Load-out, sales, returns, damages, and end-of-day reconciliation all move stock between locations that are themselves moving. Getting this wrong shows up as shrinkage nobody can explain.
- Invoicing on the device has to be legally and numerically correct, offline, with sequential document numbering that cannot collide when several devices have been disconnected for hours.
- Cash collection makes reps accountable for money. The system has to track what each rep collected, what they have remitted, and what is outstanding — which is a reconciliation problem, and a delicate one, because it is also a trust problem between a company and its staff.
- Route and visit discipline. Which outlets were planned, which were actually visited, and what happened at each — this is what turns the system from a billing tool into something management uses to run the territory.
How I approached it
- The sync model before the screens. What the device owns, what the server owns, and who wins a conflict per entity — decided first, in writing, with the business. Every subsequent feature is easy or impossible depending on that decision.
- Idempotent, replayable sync. A rep’s day is a queue of events replayed against the server. Retries, duplicates, and out-of-order arrival are normal traffic, not error cases.
- Document numbering that survives partition — device-scoped sequences reconciled centrally rather than a single global counter that requires connectivity.
- The back office as a first-class product. Reps are the visible users, but the system’s value is realized by the people reconciling stock and cash. Their tooling was built as a feature, not an afterthought.
Where this is relevant to you
Any operation where work happens away from the office and connectivity can’t be assumed has this shape: merchandising, field service, inspections, deliveries, agricultural supply. Offline-first sync and conflict resolution are the hard parts, and they are architecture decisions — expensive to add to a system that assumed a network.
Working on something like this?
Start a conversation