Designing for intermittent connectivity forces a kind of honesty about failure modes that fast, reliable networks let you avoid.
Eng Abdalla
Updated Aug 29, 2026
Abdalla
thanks eng
A lot of software is designed by people who have never had to use it on a network that drops mid-request. That's not a criticism — it's just a gap in the conditions most engineering happens under. Building for markets where connectivity is intermittent rather than guaranteed changes what you treat as an edge case.
On a fast, stable connection, "the request failed" and "the request is still pending" are functionally the same event — you retry, and it resolves in under a second either way. On an unreliable connection, they're different problems that need different handling, and conflating them is where most half-broken UIs come from.
The reframe
Treat every network call as having three outcomes, not two: succeeded, failed, and unknown. Software that only handles the first two will get the third one wrong in production, silently.
A few patterns that are invisible on good networks and painful on bad ones:
The products that hold up well under bad connectivity conditions share a trait: they were built with a queue in mind, not a request-response assumption. An action gets recorded locally, gets a stable identity, and gets synced when the network allows it — rather than existing only in the moment the request completes.
Anything you build as if the underlying dependency is perfectly reliable will eventually meet a user for whom it isn't. Design for the failure mode you'd rather not think about, because someone is already living in it.
This isn't unique to low-connectivity markets — it's just where the gap between "designed for the happy path" and "designed for reality" becomes impossible to ignore. The same discipline pays off anywhere: mobile networks in transit, spotty office wifi, a laptop closing mid-upload. Build for the unreliable case, and the reliable case takes care of itself.