Offline-first is not a nice-to-have. It is the requirement.

There is a particular kind of failure that happens when a system is built for a network that does not exist. A clinician taps save and watches a spinner. A driver cannot close a delivery. A shop assistant cannot complete a sale. The connection returns, the operation fails, and the user quietly goes back to paper.

We have taken over enough of these systems to know the pattern. It is almost never a single dramatic bug. It is a design assumption, made early, that the network is reliable and always available.

Design the offline state first

The teams that get this right do something counterintuitive: they design the disconnected experience before the connected one. What does the user see when there is no signal? Can they still complete the core task? What happens to their work when the connection returns?

If you can answer those three questions clearly, the connected path is usually straightforward. If you cannot, no amount of backend engineering will save the product.

Three decisions that matter most

• Local writes, not local cache. Caching is read-only thinking. If users need to create or change records offline, you need a real local store and a sync strategy, not a cache.
• Idempotent operations. Retries are inevitable. Every write needs an identifier so that a repeated submission does not create a duplicate record. This single decision prevents most data corruption we find in the field.
• Visible sync state. Users tolerate delays they can see. A clear indicator that says 'saved on this device, not yet synced' builds far more trust than a spinner that lies.

Conflict resolution is a business decision

When two devices edit the same record, someone has to decide what wins. This is not purely technical. In clinical records, the most recent observation usually wins. In financial records, nothing should silently win and the conflict should be escalated to a human.

We write these rules down with the client before building, because the answer is always domain-specific and always better decided by the people who own the process.

If a user needs to think about whether they have a connection before doing their job, the design has already failed.

What this costs

Offline capability is not free. It adds complexity to data modelling and testing, and it demands discipline in the sync layer. In our experience it typically adds ten to twenty per cent to the build cost of an application.

Against that, consider the alternative: a system that users abandon the first week the network disappoints them. We have seen that outcome, and it costs considerably more than twenty per cent.