Offline-first web apps for load-shedding: how Zimbabwean software actually has to work

Most web apps are written assuming a stable internet connection and a desktop on mains power. In Zimbabwe, that assumption is wrong about a third of the day. Load-shedding, fibre cuts, and metered mobile data are facts of operating life. Software that ignores them generates real losses: missed sales, lost data, frustrated staff.

Here is the engineering pattern we apply when building web apps for the Zimbabwean operating environment.

1. Treat connectivity as optional, not required

Most apps fail in one of two ways when the connection drops: they freeze on a spinner, or they accept an action and then silently lose it. Both are bad. The fix is to design for queued action. Every user action is captured locally, then synced to the server when the network returns. The user keeps working; the system catches up.

2. Cache everything cacheable

Service workers and IndexedDB make it possible to serve the entire app shell, recent data, and reference lists (clients, products, prices) directly from the browser. That means a sales rep at a customer site with no signal can still open the CRM, see their pipeline, and take an order. The sync happens later.

3. Use background sync and conflict resolution

Background sync queues actions while offline and replays them when the connection returns. Conflict resolution is the harder problem. What happens when two reps update the same record offline? We default to last-write-wins for low-stakes fields and explicit merge UI for high-stakes ones.

4. Optimise for low data

Bundle size matters everywhere, but it matters more in Zimbabwe where users pay per megabyte. We keep the first load as small as possible, lazy-load everything else, compress images aggressively, and serve responsive image sizes so phones do not download desktop assets.

5. Handle authentication offline

Tokens expire while the user is offline. Refresh quietly when the connection returns, fall back to a friendly re-auth prompt only if the refresh itself fails. Never dump someone to a login screen while they are mid-task.

6. Surface connectivity status honestly

Show the user, calmly, when the app is operating offline and what is queued for sync. A small status indicator, not a panicked banner. Users in Zimbabwe are used to intermittent connectivity; they just need to know their work is safe.

7. Plan for partial failure, not just full outage

Real connectivity in Zimbabwe is rarely fully on or fully off. More commonly it is slow, intermittent, or high latency. The app needs to behave sensibly across that whole spectrum. We set short, explicit timeouts on every network call, surface loading states quickly instead of a frozen spinner, and give the user a retry control rather than a stuck screen. Anything that writes to the server is optimistic in the UI and pessimistic in the database: the action appears immediately, but the server has final say and rolls back cleanly when it cannot accept the write.

8. Test under real Zimbabwean conditions

The biggest gap between offline-first in theory and offline-first in practice is the test environment. Chrome DevTools throttling is a starting point, but it does not capture the reality of a 3G signal bouncing between two and no bars in a lift in Eastgate. Every release gets tested on real devices, on real networks, in real locations we know clients will use. The bugs you find on a Huawei Y6 in the Joina City parking garage are not the bugs you find on a Macbook in the office.

The toolkit

• Next.js with PWA support
• Service workers for offline app shell
• IndexedDB for structured client-side data
• Background Sync API for queued actions
• Optimistic UI updates with rollback on conflict
• Image optimisation and responsive sizing

The result

An app that loads quickly on a local 3G signal, works during load-shedding, syncs cleanly when the power and internet return, and treats data as precious. That is the bar for software shipped in Zimbabwe. Anything less is a liability.