Most software assumes a reliable connection. Across much of East Africa that assumption is wrong, and designing around it properly changes how a system is built.
A lot of modern software is built on the quiet assumption that the internet is always there. Drop that assumption and a surprising amount has to change - not just error handling, but how data is stored, when it's considered saved, and what happens when two people edit the same record while both offline.
Local first, sync second
The core shift is that the device becomes the primary place data lives, and the server becomes something it reconciles with later. When a user saves something, it's genuinely saved - locally, immediately - whether or not there's a connection. Syncing happens in the background when it can.
This is how we built the school management system now running at Lubiri Secondary School. Campus connectivity isn't dependable, so teachers and librarians work against a local store that syncs upward when the connection returns. From the user's side, it simply always works.
Conflicts are a design decision, not a bug
Once multiple people can edit offline, conflicts are inevitable. The question is who wins, and that depends on the data. For a meter reading, the most recent entry usually wins. For an inventory count, you may need a human to look. Deciding these rules per data type during design is much cheaper than discovering them in production.
Show people the sync state
Users tolerate offline behaviour well when they can see it. Hiding it creates anxiety - people re-enter data because they aren't sure it saved. A clear indicator showing what's pending and what's synced removes almost all of that friction.
Test on realistic conditions
That last case is where most offline systems fail, and it only shows up if you deliberately test for it. Building this way takes more thought upfront, but for a lot of businesses here it's the difference between software people use and software they work around.
