Offline-first is usually introduced apologetically. It is presented as an accommodation — a concession made for markets that have not caught up yet, a feature to be added once the important work is done.

I would put it the other way around. Designing for imperfect connectivity is one of the most useful constraints a technology team can accept, and the discipline it imposes produces better software for everyone.

The assumption worth examining

Most enterprise software carries an unstated assumption: the network is there. It is fast enough, stable enough and present at the moment the user needs it. When that assumption holds, a great deal of complexity can be pushed to the server and the client can stay thin.

When it does not hold, the same design fails in a particular way. It does not fail gracefully or partially. It fails at the exact moment someone is trying to do their job — mid-registration, mid-assessment, mid-submission — and it usually loses whatever they had entered.

I grew up in a rural community in South Africa, and the effects of that kind of failure were not theoretical. Limited infrastructure and poor connectivity did not simply make things slower. They determined what was possible. An institution that cannot reliably reach a system cannot rely on it, and a system that cannot be relied on will be worked around — usually with paper, usually in parallel, usually at the cost of the data quality the system was supposed to deliver.

The problem is not that connectivity is imperfect. The problem is software that treats perfect connectivity as a precondition.

What the constraint actually forces

Once you accept that the network may not be there, a series of design decisions follow. Each of them, taken on its own merits, improves the product.

You have to know what the client can do alone. If work must continue without a server, you have to be explicit about which operations are genuinely local and which require authority from elsewhere. That forces a clarity about the system’s model that connected software often avoids.

You have to take data volume seriously. Payloads that are merely inefficient on a fast connection become unusable on a slow one. Designing for constrained bandwidth means measuring what you send, sending less, and sending it less often. Every user benefits from that, including the ones on fibre.

You have to design for conflict. If two people can act on the same record while disconnected, you must decide what happens when both reconnect. That question is uncomfortable, and connected systems frequently duck it — right up until a race condition produces two versions of the truth anyway. Offline-first forces the conflict rules to be defined deliberately rather than discovered in production.

You have to make state visible. When some work is pending and some is confirmed, users need to see the difference. Building that clarity produces interfaces that are more honest about what the system knows — a property worth having regardless of connectivity.

You have to treat recovery as a feature. Connected software often treats an interruption as an error. Offline-first treats it as an ordinary event with a defined path back. That mindset produces software that survives contact with the real world.

None of these are concessions. They are the characteristics of resilient systems.

Resilience is not a regional requirement

It is tempting to file offline-first under “emerging markets” and move on. That framing is convenient and wrong.

Connectivity is uneven everywhere. A campus building with poor coverage, a rural training centre, a venue hosting an assessment, a mobile connection on a commute, a data centre incident on the provider’s side — these are not exotic African conditions. They are ordinary conditions that most software handles badly because it was never designed to handle them at all.

Software built to work when the network is absent works better when the network is merely unreliable. Software built assuming a good connection degrades sharply the moment conditions slip. The first design is strictly more robust than the second, in every market.

This is why I regard offline capability as a strategic property rather than a regional feature. It is a claim about how the system behaves under stress, and every institution eventually operates under stress.

The cost is real, and it is worth paying

I want to be honest about the trade-off, because pretending it is free would be a disservice to anyone weighing the decision.

Offline-first is harder. It requires state on the client, a synchronisation model, conflict resolution, careful thinking about authority and ordering, and a testing approach that deliberately simulates failure rather than avoiding it. It is more expensive to build and more demanding to maintain than a purely connected equivalent.

But the cost is front-loaded, and it is paid once. The alternative cost — institutions maintaining parallel paper processes because they cannot trust the system, data captured twice, records reconciled by hand, adoption stalling because staff have learned that the software fails when they need it — is paid continuously, by the customer, forever.

There is also a strategic dimension. Building this capability late is significantly harder than building it early. Retrofitting offline behaviour into an architecture that assumes a server is available is close to a rewrite. The decision is effectively made at the beginning, whether or not it is made consciously.

What it signals to institutions

There is a final point that has less to do with architecture and more to do with trust.

When an institution operating in a constrained environment evaluates a platform, it is asking an implicit question: was this built by people who understand where we work? Software that assumes ideal conditions answers that question clearly, and not in its own favour.

Designing for real conditions is a form of respect. It says the institution’s environment was treated as a design input rather than a deficiency. In my experience, that shapes adoption at least as much as any feature list.

The discipline, restated

Offline-first is not about being offline. It is about refusing to assume the conditions under which your software will be used.

That refusal produces smaller payloads, clearer models, explicit conflict rules, honest interfaces and graceful recovery. It produces software that works in a rural training centre and works better in a well-connected boardroom.

Treated as a limitation, it looks like a constraint imposed by the market. Treated as a discipline, it is one of the more reliable routes to building technology that holds up.

I would rather build for the harder condition and inherit the easier one.