Why software sold in Ghana has to work without a network

Most business software sold here was designed somewhere the network is assumed. When it drops, the screen says to try again, and the person holding the phone writes the delivery on the back of the docket and promises themselves they will enter it later. They enter about half.

The design question is not whether to handle a lost connection. It is what the software does with the action somebody has already taken.

Four things decide that, and they are the ones we built for. The action is taken rather than refused: a delivery confirmed with no signal is confirmed, and it joins a queue the person can see and count. A photograph taken out of coverage is held at the size it was taken rather than dropped. The queue drains by itself when signal returns, so nobody has to remember to press anything. And an action the server later refuses is shown with the reason, on the phone that made it, rather than disappearing.

The fourth one is the one that gets skipped, and it is the one that decides whether anybody trusts the other three.

Not every screen can work this way and we do not pretend otherwise. Taking work offline is built where the work happens offline — field jobs, deliveries, stock counts. A report that adds up a year of ledger entries needs the server, and asks for a connection rather than guessing.