Most software assumes the network is there. It assumes a payment gateway responds in under a second, that a sync runs quietly in the background, and that a failed request can simply be retried. Build on those assumptions in Kinshasa, Lubumbashi or a market town in the interior, and the product stops working the moment it matters most.
Offline-first is not a feature you add later. It is a decision about where the truth lives. In a connected app the server holds the record and the client displays it. In an offline-first app the device holds a real record, and the server reconciles. That inversion touches your data model, your identifiers, your conflict handling and your entire testing strategy — which is why retrofitting it is so expensive.
The practical consequences are specific. Generate identifiers on the client, not the server, so a record created without a connection is never waiting for permission to exist. Store an operation log rather than overwriting state, so two devices that both edited the same customer can be merged rather than one silently winning. Make every write idempotent, because a request that timed out may well have succeeded.
Cash changes the design too. A transaction that settles in physical notes has no gateway callback to wait for and no automatic reconciliation. The system has to record an intent, let a human confirm it, and hold the difference between the two states without losing either. Teams used to card-based flows tend to model this as an edge case; in a cash-dominant economy it is the main path.
None of this is exotic engineering. It is the ordinary discipline of not assuming your own conditions are universal. Build for intermittent connectivity and cash, and the product still works perfectly on fibre in Frankfurt. Build the other way round and it fails everywhere the assumptions do not hold — which, globally, is most places.