Shipping software to Zimbabwean clinics: internet-first is wrong.

There is an architectural assumption baked into most modern web frameworks: that the network is fast and present. State-of-the-art Next.js, Remix, SvelteKit — all of them assume that React Server Components or hydration or partial pre-rendering can hit a backend in 80ms reliably. That assumption is largely true in San Francisco. It is variably true in Lagos. And it is regularly false in a rural primary care clinic in Mashonaland Central, where a 3-hour load-shedding window can knock out the local cell tower’s diesel backup right at the moment a nurse is trying to record a child’s immunisation.

For most of the consumer web, the assumption is fine. If your e-commerce site loads slowly on a bad day, the customer comes back tomorrow. But for clinical software, an offline moment is the difference between a record being captured and a record being lost. We have made that mistake. Once.

The lesson — and now the foundational principle of every system we ship into low-bandwidth environments — is that the source of truth has to be local. The cloud is the eventual-consistency layer, not the primary store. The clinician’s tablet is the canonical state. Sync is a background concern.

Architecturally, what this looks like in our stack:

Local-first writes. Every record is created and persisted to an indexed local store (IndexedDB or SQLite via Capacitor) before it is sent anywhere. The UI never blocks on network. The user does not know — or care — whether they are online.

Conflict-free replicated data types (CRDTs) or last-writer-wins with vector clocks. When two clinicians edit the same record while disconnected, the resolution is automatic and deterministic. We use Yjs for collaborative editing scenarios and a hand-rolled LWW protocol for single-record edits.

Sync queue with exponential backoff. When the network returns, an outbox flushes pending writes in order. Failures retry with backoff. The user sees a quiet sync indicator. They do not see modal dialogs.

Stale-while-revalidate everywhere on read. A nurse pulling a patient record gets an instant render from local cache, with a background refresh from the server. If the server is unreachable, the local cache is the answer. The screen never spins waiting for a network call.

Power-loss safety. The tablet is going to die mid-write. Always assume so. Every transaction is wrapped, every operation is idempotent on retry, and every write that requires confirmation is committed locally before any UI feedback is given.

There is a related discipline that we call “quiet sync UX”. The default modern dev instinct is to surface every network state — “syncing”, “offline”, “connection lost”, “reconnecting”. In a clinic, this is psychological noise. Clinicians are already managing 14 things at once. The system should sync silently and only interrupt them when something the human actually needs to know about has happened — for example, a write conflict that needs adjudication.

Building this way is more work upfront. About 25–35% more engineering effort versus assuming connectivity, in our calibration. It is also the reason our healthcare clients average 99.97% effective uptime measured at the user, against an environment where the underlying connectivity averages closer to 91%. Local-first absorbs the gap.

A smaller, related point. We default to React Native or PWA architectures for clinical apps in this environment, not pure web. The native shell makes background sync, persistent storage, and edge-case OS recovery dramatically more reliable. A pure web app on a chromium tablet is fragile in ways that don’t show up in office demos.

If you’re building software for clinics, schools, or field operations in Zimbabwe and the broader region, we’d encourage you to invert your default. Internet-first is the wrong starting point. Local-first is the right one. The cloud is the eventual-consistency partner, and that is enough.