Engineering

Building for the moment the connection drops

A sales app that stops when the signal does is not a sales app. It is a form that happens to be on a phone.

Coverage is not a constant here. A rep is in a shop with three bars, then in a warehouse with none, then on a road where it comes and goes. If the software treats the connection as a given, every one of those becomes a person standing still, holding a phone, watching a spinner.

The fix is architectural rather than cosmetic. An offline-first app keeps its own copy of what it needs on the device: the catalogue, the prices, the customer list, the stock figures as of the last sync. Orders are written locally and queued. Nothing about the workflow changes when the signal goes, which is the entire point.

When the connection returns, the queue drains into the central system on its own. The interesting work is in the conflicts: two devices editing the same customer, a price that changed while a device was dark, an order taken against stock that has since sold. Those rules are a business decision rather than a developer's guess, and we settle them before the first screen is drawn.

Building this way costs more. It is also the difference between software the field team uses and software the field team routes around, which is why we ask about coverage in the first conversation instead of discovering it at the pilot.

All insights

Let's scope your project.

Tell us how your business needs to operate. We'll send a clear, no-obligation quote.