A business owner in Vientiane or Yangon who decides to get serious about systems usually starts in the same place: a global platform. Shopify for the shop. Xero for the books. Google Workspace for the team. These are excellent products, built by large teams, and they cost a fraction of anything custom.
Often that is the right answer, and it is worth saying so plainly. If you sell physical products online and take card payments, Shopify will serve you better than anything we could build. If you need accounting, Xero and QuickBooks have decades of work behind them. If you need email and documents, Google Workspace is finished, reliable, and cheap.
Most businesses do not need custom software. They need to adopt good tools properly and train their staff.
But some businesses try exactly that, do it competently, and still end up back on paper within a year. Not because they chose the wrong platform, and not because the staff resisted it. Because a specific assumption inside the software did not hold where they operate.
It is worth knowing which assumptions those are, so you can tell early which situation you are in.
The address assumption
Almost every logistics, delivery, and field-service tool in the world assumes a delivery address resolves to a location. You type an address, a map returns a pin, and the system routes from there.
In much of Southeast Asia, that chain breaks at the first step. We built a distribution platform where many of the retail shops being delivered to were simply not on any map. There was no address to geocode. Drivers found shops by memory and by asking neighbours, and deliveries failed whenever the person who knew the route was unavailable.
No configuration setting fixes this, because the software is not wrong. It is correctly built for markets where addresses exist. The gap is in the world, not the code.
What worked was building the map as part of the product: GPS-pinning each shop on the first successful delivery, with a photo of the shopfront so the next driver would recognise it. Once locations existed as data, routing became possible and orders could be clustered by zone. Delivery costs fell 60%.
The payment assumption
Global commerce platforms are built around cards and digital wallets. The entire order lifecycle assumes payment is confirmed before or at purchase, which makes the transaction a solved problem by the time fulfilment begins.
Where cash on delivery dominates, that lifecycle inverts. Payment happens last, in cash, in the hands of a rider, far from any system. The hard problem is not taking the order — it is reconciling what was collected against what was owed, and knowing who held the money at each step.
A logistics company we worked with was losing revenue precisely there. The parcel lifecycle was entirely paper-based, with no visibility into who had handled what. The answer was a digital chain of custody: barcode scanning at each handoff, geo-stamped photo proof of delivery, and automated reconciliation displaying the exact expected cash amount at settlement. Revenue leakage went to zero.
You will not find that flow in an off-the-shelf commerce platform, because in the markets those platforms were designed for, it is not a problem.
The connectivity assumption
Modern web applications assume the network is available. Not fast necessarily, but present. Autosave, live sync, and real-time dashboards are all written by people who expect a request to resolve within a second or two.
When connectivity is intermittent, that assumption does not degrade gracefully — it fails at the worst moment, which is during a busy trading hour when someone is trying to place an order.
For a merchant app serving neighbourhood shops, we made offline the normal case rather than the exception: orders are captured locally and sync automatically when signal returns. The shop owner never thinks about the network. Order placement time dropped 90% and failed deliveries approached zero.
Some global tools do offer offline modes. It is worth testing them honestly under real conditions before committing, rather than trusting the feature list.
The device assumption
Software companies build for the devices their teams carry. That is not a criticism, it is simply how product decisions get made — and it means the minimum supported device tends to be a recent smartphone on a stable data plan.
For a supermarket expanding through neighbourhood shops as sales agents, the shop owner had a phone but the end customer often did not have the app, and would never install one. Requiring a customer download would have eliminated most of the market on day one. Delivery updates went out over automated SMS instead — no app, no account, no data connection needed. The merchant app itself was kept under 1 MB so it would run on 2G.
Unglamorous, and it works on every handset in the country.
The pricing assumption
This one is less discussed and often decides the outcome.
Global SaaS is priced per user per month against wages in the markets where it was built. A tool at twenty dollars per user monthly is trivial for a firm in Singapore and genuinely expensive for one in Vientiane running thirty staff. The arithmetic that makes the product obviously worth buying in one market makes it obviously not worth buying in another.
Businesses often respond by sharing logins, licensing only managers, or using the tool for part of the workflow and paper for the rest. That produces the worst outcome available: paying for software, and still not having a single reliable record of what happened.
If you find yourself rationing seats, that is a signal worth taking seriously. It usually means the tool is not economically fitted to your market, whatever its feature list says.
What to actually do
Four options, roughly in order of what you should try first.
Change your process to fit the tool. Underrated, and frequently correct. Established software encodes a lot of accumulated experience about how a process can work. If your way of doing things is merely habit rather than a genuine local constraint, adapting is far cheaper than building. Be honest about which one it is.
Use the tool for what it fits, and something else for the rest. Accounting in Xero, operations somewhere else. This works when the boundary between the two is clean. It fails when data has to move back and forth constantly, at which point someone ends up retyping everything and you have created a job rather than solved a problem.
Integrate around the platform. Keep the global tool as the system of record, and build a thin layer handling the parts it cannot: a lightweight app for field staff, an SMS notification service, a reconciliation process. Much cheaper than a full custom build, and you keep the platform's ongoing development. Worth checking the API is genuinely capable before relying on this.
Build custom. Justified when the mismatch is structural rather than cosmetic — when the software assumes something about addresses, payment, connectivity, or devices that is simply not true where you operate, and no configuration reaches it. That is a real cost and should be a considered decision, not a first instinct.
How to tell which one you are in
A few questions worth answering before you spend anything.
- Is the mismatch a preference or a constraint? "We have always done it this way" is a preference. "Our customers do not have smartphones" is a constraint. Only the second justifies building.
- What happens today when the network drops? If the answer is that work stops, and work stopping is expensive, that is a structural gap.
- Are you rationing licences? If people share logins to control cost, the tool is not priced for your market and the workaround is corrupting your data.
- How much of the process still lives on paper? A system covering 60% of the workflow while the rest sits in notebooks is often worse than either extreme, because nothing reconciles.
- Could you hand this over? Whatever you build or buy, someone else should be able to maintain it. If the answer depends on one person's memory, you have a different problem.
The general point: imported software is not badly made, and the businesses that struggle with it are not behind. The tools were built for a different set of conditions, and most of the time that difference does not matter. Occasionally it matters completely.
Knowing which case you are in before you commit budget is most of the decision.