There is a particular moment that kills field software. A technician is standing in a plant room, or a driver is at a farm gate, or a stock controller is deep in a steel-clad warehouse. They tap save. The wheel spins. Nothing happens. They try again, lose the form, and from that day forward they write it on paper and type it in later, exactly as they did before you spent the money.

Software that assumes a good connection does not fail politely. It fails at the worst moment, in front of a customer, and it never gets a second chance with the person it failed.

Connectivity here is not a solved problem

It is tempting to treat reliable connectivity as a given, because in an office it usually is. Step outside and the picture changes fast. Load-shedding takes down the tower as readily as the office router. Warehouses and basements have dead zones by construction. Rural coverage varies from adequate to theoretical. Data costs make people switch off mobile data between tasks. And a device with one weak bar is often worse than a device with none, because everything hangs instead of failing quickly.

None of that is exotic. It is a normal Tuesday for anyone doing deliveries, inspections, installations, meter readings, agriculture or site work in this country.

What offline-first actually means

Offline-first is not a feature you bolt on at the end. It is a decision about where the truth lives while the work is happening. In a connection-dependent app, the server owns the data and the device is a window onto it. In an offline-first app, the device holds a working copy, the user carries on regardless, and synchronisation happens whenever it can.

  • Local storage that is real. Captured work is written to the device immediately, so closing the app, going flat or losing signal costs nothing.
  • A queue, not a hope. Pending changes sit in an explicit outbox that retries. The user can see how many items are waiting, which builds trust faster than any reassurance.
  • Sync that resolves conflicts on purpose. Two people edited the same record on different devices. The system needs a stated rule for that, decided by you, not an accident of whoever synced last.
  • Identifiers generated on the device. If a record cannot exist until the server names it, you are not offline-capable, no matter what the brochure says.
  • Honest status. Show clearly what is saved locally and what has reached the server. Ambiguity here is what makes people distrust the app.
The question is never "will the connection drop?" It is "what does the person do in the four minutes after it does?" If the answer is a piece of paper, your project has already failed.

The cost, stated plainly

Offline-first is more work. Sync logic, conflict rules, local storage and testing under bad conditions all add build time, and anyone claiming otherwise has not done it. It is worth being deliberate about where you spend it. A finance approval screen used only at head office does not need it. A job card completed at a customer's premises absolutely does.

The middle path is usually right: make the capture path offline-capable and leave the reporting, admin and configuration screens online-only. That covers the moments where failure is expensive without paying the complexity tax across the whole system.

Test it properly, once

Put the device in flight mode, complete a full day's worth of work, close the app, restart the phone, then reconnect. Everything should arrive, once, in the right order, with nothing duplicated or lost. Teams that run this test before go-live rarely have field adoption problems. Teams that do not, always find out the hard way.

Power is the other half

Connectivity gets the attention, but power outages take out the same processes and often the same day. The practical implications are unglamorous: prefer devices that last a shift, keep an offline copy of anything the team needs to read as well as write, and make sure your own critical services degrade gracefully rather than collapsing when a data centre or an office switches to backup.

The same design instinct covers both. Assume the infrastructure will be unavailable at some point and decide, in advance, what happens then.

Build for the worst day

Systems that work perfectly under ideal conditions are easy and largely useless, because ideal conditions are not where the money is made. The delivery still has to be signed for. The inspection still has to be recorded. The stock still has to be counted.

Design for one bar of signal and a phone at eleven percent, and the good days look after themselves.