Most software is built on an assumption its authors never state out loud: that the network is there.
Not fast, necessarily. Just there. The request goes out, the response comes back, and the interface updates. Every loading spinner, every autosave, every "syncing..." toast is written by someone who expects the connection to resolve within a second or two.
Across much of Southeast Asia, that assumption breaks. Not occasionally, and not only in remote areas. It breaks in the middle of a working day, in a shop on a busy street, while someone is trying to place an order they need delivered tomorrow.
We have spent the last two years building delivery, distribution, and commerce platforms for businesses operating in exactly those conditions. Here is what actually mattered.
Design for the network you have
The instinct when connectivity is poor is to optimise. Compress the images, lazy-load the routes, add a retry.
That helps, but it treats intermittent connectivity as a degraded version of good connectivity. It is not. It is a different operating condition, and it needs different decisions at the architecture level, not the optimisation level.
For a virtual inventory platform we built for a central supermarket, the merchant app had to run on minimal mobile data, including 2G networks. That constraint could not be met by trimming a normal app. It had to be a design input from the first architecture decision, and it produced a very different application: under 1 MB total, with a purchase flow that completes in under two minutes on a shop counter.
If you retrofit for low bandwidth after the fact, you will get an app that technically loads and that nobody can actually use during a busy hour.
Offline-first is not the same as offline-tolerant
There is a meaningful difference between an app that survives losing connection and an app that assumes it will.
Offline-tolerant means the app shows an error and asks you to try again. Offline-first means the shop owner places the order, the order is captured locally, and it syncs automatically when signal returns. The person on the counter never thinks about the network at all.
For a B2B distribution platform connecting wholesale hubs to neighbourhood retail shops, we built offline order queuing directly into the merchant app. Orders placed without connectivity are stored and transmitted the moment the connection is available.
The operational result was not a better user experience in the abstract sense. It was a 90% reduction in order placement time and a failed delivery rate close to zero, because orders stopped being lost in the gap between intent and connectivity.
Not everyone has the app
This is the constraint teams from high-connectivity markets miss most often.
In the supermarket network, the shop owner has the merchant app. The end customer usually does not. Building a customer-facing app and requiring a download would have eliminated most of the addressable market on day one.
So delivery updates go out over automated SMS at each stage of fulfilment. No app, no account, no data connection required on the customer side. It is unglamorous, and it works on every handset in the country.
The general principle: your users are not one homogeneous group with one device profile. Build for the actual distribution of devices in the market, not the one your team carries.
The map does not exist
A logistics assumption that holds in most of the world is that a delivery address resolves to a location.
For the wholesale distribution network, many shop locations were simply unmapped. There was no address to geocode. Drivers were finding shops by memory and by asking, and deliveries failed when the person who knew the route was unavailable.
The fix was to build the map ourselves: a GPS-pinned shop location system, captured on first successful delivery, with photo verification so the next driver recognises the shopfront. Once locations existed as data, route optimisation became possible, and orders could be clustered by zone into consolidated loads rather than sent out as individual trips.
That change alone cut delivery costs by 60%.
The wider lesson is that missing infrastructure is sometimes something you build as part of the product rather than something you wait for.
Verification when you cannot rely on paper
In a Cash on Delivery logistics business we digitised, the entire parcel lifecycle had been paper-based. There was no visibility into where a parcel was, who had handled it, or whether the cash collected matched the amount owed.
The answer was a digital chain of custody: barcode scanning at every handoff, geo-stamped photo proof of delivery, customer signature capture, and automated reconciliation that displays and matches the exact cash amount at settlement.
Each of those individually is a small feature. Together they closed the revenue leakage entirely and took merchant fraud to zero, because every step in the chain became attributable.
Worth noting: geo-stamped photo proof also needs to work when the rider has no signal. The verification is captured on the device and uploaded later. Same offline-first principle, applied to a different problem.
What this means if you are building for the region
If you are commissioning software for operations in Laos, Myanmar, Thailand, or comparable markets, a few questions are worth asking any development partner before work begins.
- What is the minimum network condition this is designed for? If the answer is a version of "it should be fine," the assumption has not been examined.
- What happens to a transaction started without connectivity? The answer should describe a queue, not an error message.
- What device is the least-equipped user carrying? If the plan assumes a recent smartphone with a stable data plan, some portion of the market has been excluded without anyone deciding to exclude it.
- Does this depend on infrastructure that exists here? Addresses, mapping data, payment rails, and identity systems vary enormously by market. Building on top of infrastructure that is not there is the most expensive kind of assumption.
None of this is exotic engineering. It is ordinary engineering with a different set of constraints taken seriously from the start, which is considerably cheaper than discovering them after launch.