The assumptions most software makes are wrong here

Most software is designed for a world of fast, always-on connections and cheap data. That world is not South Africa. Building offline-first apps for South African conditions means starting from the opposite assumptions: the power will go, the signal will drop, and every megabyte a user spends is money they may not have. A load-shedding-proof app is not a nice-to-have on this continent. It is the baseline for software that people can actually rely on.

The failure is easy to picture. Load-shedding takes out the cellular tower, so an entire suburb loses coverage at once. A student opens a study app in a taxi and the signal drops between stops. In a township with thin coverage, the connection is there and then it is not. Data is expensive, so a heavy app that re-downloads everything on every screen quietly burns through an airtime budget. Software built for fibre in a European office treats all of this as an edge case. For millions of South Africans it is the normal case.

What offline-first actually means

Offline-first is a design stance, not a single feature. The core idea is simple: the app works from a local cache first, and syncs with the server when the network returns. The user never sits and waits on a connection that may not come.

In practice it comes down to a handful of plain principles. Read from the local store first so the last known data is always on screen instantly. Queue actions locally and replay them when connectivity comes back, so a form a user submitted in a dead zone is not lost. Cache the pages and data a user has already visited, because the things they looked at once are the things they are most likely to want again. Never block the whole screen waiting on a request — show what you have and fill in the rest quietly. And keep payloads small, because respecting a user's data cost is as much a design decision as any button or colour.

Proof from our own work

We do not treat this as theory. VarsityOS, our student super-app, is offline-capable and built explicitly for these realities. It is R50-meal-aware and NSFAS-aware because that is the actual budget its users live on, and it is designed for students who are studying through load-shedding, not around it. It has 130 real users — a real number, not a projection.

This very website is another example. It ships a hand-rolled service worker — a small Progressive Web App layer — that caches the pages you have already visited and shows a branded offline page when the connection drops. If load-shedding cuts your signal mid-visit, the site does not collapse into a browser error. It degrades into something we designed on purpose.

The honest limits

Offline-first is not a claim that everything works offline. It cannot. Real-time payments need a live connection to clear. Genuinely live data — a price that changes by the second, a message someone is typing right now — needs the network by definition. Pretending otherwise would be dishonest and would break trust the first time it failed.

So the craft is not making everything offline. It is choosing well: deciding what should degrade gracefully and what must stay online. A student's notes, their timetable, the pages they read yesterday — all of that can and should work with no signal. A card payment should tell them plainly that it needs a connection, rather than spin forever and lose their money in the ambiguity. Knowing which is which is the whole job.

Designing for African infrastructure is just better engineering

There is a temptation to frame all of this as a compromise — as building down to meet poor conditions. It is the opposite. An app that keeps working when the tower is down, replays what you did when the signal returns, and refuses to waste your data is simply more resilient software. It happens to be essential in South Africa. It also happens to help everywhere: on a plane, in a lift, on a dodgy hotel connection, on the London Underground.

Designing for African infrastructure realities is not a downgrade. It is a discipline that produces better, more honest software — built for the conditions people actually live in, rather than the ones a datasheet assumes.