Offline-first is not optional in Nepal — it is the baseline

When we started building clinical records for rural clinics in Province 2, we assumed connectivity would be occasional. It was the default state. Staff worked for hours with no signal, then walked to a ridge where a single bar appeared. Any architecture that treated the network as reliable failed within the first week of piloting.

The instinct for most teams is to add a loading spinner and a retry button. That works when failures are rare. When failures are the normal condition, the product has to be designed around local state from the very first screen: every action writes locally, the interface reflects local truth immediately, and synchronisation becomes a background reconciliation problem rather than a blocking operation.

The hard part is not storing data locally. It is conflict resolution. Two clinic staff can register the same patient on two tablets during a network partition. A stock transfer can be initiated twice. Our approach has settled into a predictable pattern: every record gets a client-generated UUID, an immutable operation log, and a last-writer-wins policy only where the domain genuinely permits it. For clinical records, we never use last-writer-wins — we surface the conflict to a human.

This is slower to build than a naive REST integration. It is also the difference between a system that gets used and one that gets abandoned. If you are building for users outside the Kathmandu valley, budget for it in the first estimate, not the third sprint.