Most logistics software is designed for a world of clean addresses, card payments, and dense courier networks — then exported to markets where none of those assumptions hold. We took the opposite path and built for Asia's realities first. That single decision shaped the product in ways that turned out to matter far beyond the region we started in.
The assumptions that don't travel
A platform built for a Western market quietly bakes in assumptions: that every address is a precise, standardised line; that payment happens online before delivery; that a handful of large carriers cover the map; that a failed delivery is a rare exception.
Carry that software into much of Asia and each assumption breaks. Addresses are often landmarks and descriptions, not grid coordinates. A large share of orders are paid in cash on delivery. Coverage is a patchwork of national carriers, regional players, and independent riders. And failed first attempts are common enough that they have to be a designed-for path, not an edge case.
Cash on delivery as a first-class citizen
Nowhere is the difference starker than payments. In many markets, cash on delivery isn't a fringe option — it's how a huge share of commerce actually gets paid. Bolt COD onto a card-first system and you get a mess of manual reconciliation and constant disputes.
We treated COD as core from day one. Every COD amount is tied to its shipment, collected against the driver at handover, and reconciled automatically as cash is banked and remitted. The money's journey home is tracked as carefully as the parcel's journey out.
Addresses that reflect reality
When addresses are descriptive rather than structured, forcing customers into a rigid form just produces bad data. Instead, the system has to work with landmarks, notes, saved locations, and a rider's local knowledge — and get smarter over time as it learns which descriptions map to which doors.
- Flexible address capture, not a rigid line-1/line-2 straitjacket
- Saved and reusable locations for repeat recipients
- Rider feedback that improves the map with every delivery
Designing for the failed attempt
Because failed first attempts are common, they can't be an afterthought. Rescheduling, redirection to a pickup point, and clear recipient communication are built into the main flow, not buried in an exceptions module. The result is fewer wasted trips and less customer frustration — in any market, as it turns out.
Why starting hard made the product better
Here's the surprise. Building for the harder environment first produced software that's more robust everywhere. A system that gracefully handles messy addresses handles clean ones effortlessly. One that treats failed attempts as normal is simply more resilient. One that reconciles cash can certainly reconcile a card.
Constraints, taken seriously, are a design gift. They forced us to build flexibility that a comfortable starting market would never have demanded.
Lessons that generalise
The most surprising thing about building for a hard market first is how much of what you learn turns out to be universal. The specific problems were regional; the design principles they forced on us weren't.
Take flexibility around addresses. We built it because addresses in our home markets are often descriptive rather than structured. But rigid address forms produce bad data everywhere — even in markets with tidy postal systems, people fat-finger fields, apartments go missing, and businesses move. A system designed to be forgiving and to learn from corrections is simply better, regardless of geography.
The same is true of designing for the failed attempt. We treated re-delivery as a main path because first attempts fail often in dense, informal environments. But first attempts fail everywhere — people are out, buildings are locked, instructions are unclear. An operation that handles that gracefully as a normal case, rather than an exception bolted on later, is more resilient in any market.
Even cash on delivery, the most region-specific feature we built, taught a general lesson: that the financial journey of a shipment deserves as much design attention as its physical journey. A system that meticulously reconciles cash can trivially reconcile cards, and the discipline of never letting money and movement drift apart pays off in cleaner books everywhere.
The broader point is that constraints are a design gift. A comfortable starting market lets you get away with rigid assumptions, because they mostly hold — until you try to expand and discover your product can't bend. Starting where the assumptions break forces you to build the flexibility in from the beginning. We didn't set out to build a more adaptable product by choosing a harder market; we just couldn't have built a fragile one and survived. That the result travels well was the happy surprise.
Local knowledge as a moat
There's a final advantage to starting where the problems are hardest, and it's the most durable one: local knowledge compounds into something competitors can't easily copy. A platform built far away and generalised inward can replicate features, but it can't easily replicate the thousands of small, specific understandings that come from operating in a difficult market every day.
Which descriptions map to which doors. How cash actually flows through a particular market's informal economy. Which lanes are reliable in the monsoon and which aren't. How recipients prefer to be contacted, and when. None of these show up in a requirements document; they're learned, painfully and gradually, by being present. And because they're encoded into how the product behaves rather than into a marketing page, they're hard for a distant competitor to see, let alone reproduce.
That accumulated local knowledge becomes a genuine moat. A newcomer can match your feature list in a quarter; matching your understanding of the ground takes years of operating on it. Starting in the hard market didn't just make the product more adaptable — it built a store of hard-won knowledge that keeps paying off long after the initial features are commoditised.
The takeaway
We built for Asia first not as a limitation but as a strategy. The realities we designed around — cash, messy addresses, patchwork coverage, frequent re-attempts — made the product tougher and more adaptable than it would ever have been if we'd started somewhere easy and tried to generalise later. Hard markets make good software.