Building for two bars of signal
Why offline-first is not a premium feature in Pakistan and the Gulf, and the three patterns we use to make software survive a bad connection.
A great deal of software is designed in offices with fibre and tested on the same. Then it ships to a campus on the edge of a city where the connection drops for ninety seconds at a time, and everyone is surprised.
Connectivity is not a rare failure case here. It is the normal operating condition. Three patterns cover most of it.
Write locally, sync in the background
The most damaging design decision is making the user wait for the network before their action is acknowledged. A teacher marking attendance for thirty-eight students should never see a spinner.
Write to local storage immediately, show the action as done, and reconcile with the server when the connection allows. The user's mental model — "I marked it, it's marked" — stays true regardless of the network.
This requires deciding what happens on conflict, which is real work. But the alternative is a teacher tapping the same button four times because nothing appeared to happen.
Make the queue visible, not alarming
If there is unsynced data, say so — but calmly. A small "3 items pending" indicator is honest and reassuring. A red error banner for a condition that will resolve itself in forty seconds trains people to ignore your warnings.
Reserve alarming UI for states that genuinely need a human: a conflict that cannot be resolved automatically, or data that has been pending long enough to be at risk.
Design the payload before the interface
A dashboard that pulls two megabytes of JSON to render four numbers is fine on fibre and unusable on a shared campus connection. Decide what the screen actually needs, and send that.
In practice this means server-side aggregation rather than shipping raw records to be summed in the browser, pagination that defaults to sensible sizes, and images that are sized for the element they land in. None of it is clever. All of it is skipped constantly.
The test that matters
Throttle your connection to 3G with 10% packet loss and use your own software for ten minutes. Not a click-through — actually complete a real task.
Almost everything that needs fixing surfaces in that ten minutes. Most teams never run it, which is precisely why it remains such a reliable way to find problems.