THE GIST
Building for African conditions and building to global standard are the same discipline. What that looks like in practice.
A perspective from Lognetics Editorial · 2 min readDesigning for the network you actually have
A great deal of enterprise software assumes a stable connection, and handles its absence as an error state. For much of the world, intermittent connectivity is not an error. It is Tuesday.
Designing for it changes the architecture rather than the error messages. Local-first data models so work continues offline. Conflict resolution that is decided deliberately rather than by whichever request arrives last. Queued operations that survive a closed laptop. Payloads sized for metered mobile data.
None of this is exotic. It is simply taken seriously, and systems built this way feel notably better on good connections too, because latency hiding is indistinguishable from speed.
The device on the other end
The person using the system is frequently on a mid-range Android phone on a metered plan, not the workstation the interface was designed on. That single fact should discipline every front-end decision.
It means budgeting JavaScript rather than accumulating it, rendering meaningful content on the server, treating images as a performance surface rather than decoration, and testing on representative hardware instead of a simulator on a fast laptop.
Performance is often framed as a technical nicety. On a metered connection it is an access question: a heavy page is a page some of your users cannot afford to load.
Accessibility and resilience are the same instinct
Keyboard navigation, honest contrast, respected reduced-motion preferences, meaningful alternative text and interfaces that survive a failed script are usually filed under accessibility. They are equally a resilience practice, because they are what keeps a system usable when something goes wrong.
A page whose content depends entirely on JavaScript is one failed request from blank, for a crawler as much as for a person. Server-rendering the substance is the same decision as making it accessible and the same decision as making it indexable.
This is what we mean by a standard that travels. Not a different bar for different markets, but engineering that holds up under the hardest conditions it will meet, which is the only bar worth setting.
