Building software for markets big tech ignores

A lot of default software architecture — the kind you get from following a popular tutorial or copying a well-funded startup's stack — quietly assumes a card-based payment processor, a reliable connection, and a courier API with clean, documented coverage. Build for Bangladesh, or most of South and Southeast Asia, or plenty of the rest of the world, and every one of those assumptions is wrong often enough that it can't be treated as an edge case.

Cash-on-delivery isn't a legacy method to phase out

In a lot of these markets it's the majority of transactions, not a fallback for the unbanked minority. That changes the data model, not just the payment options list: an order can be "confirmed" without being "paid," and reconciliation has to account for a driver collecting cash days after the order was placed, sometimes for less than the order total when a customer disputes an item at the door. Software that assumes payment and order confirmation happen at the same moment breaks on exactly this flow.

"Payment gateway" usually means several regional ones

bKash, Nagad, and a bank transfer flow, often alongside — or instead of — a card processor. Each has its own webhook behavior, settlement timing, and failure modes, and they need to be designed for from the start rather than bolted on after the architecture already assumed one processor. Retrofitting a second payment rail into a system built for exactly one is a bigger rewrite than it looks from the outside.

Delivery networks are a patchwork — treat them as pluggable

Pathao, Steadfast, RedX, and a dozen other regional couriers each have different APIs, different coverage areas, and different reliability by neighborhood. Hardcoding an integration against one of them is a rewrite waiting to happen the day a business needs a second courier for a route the first one doesn't reliably cover — and that day comes sooner than most teams plan for.

Build for the connection you'll actually get

Testing on office Wi-Fi hides precisely the failure modes — slow 3G, a request that drops mid-upload, a session that needs to resume rather than restart — that show up the moment a real customer opens the app on a real connection. If the team building the product has never tested it on a throttled connection deliberately, that's the first gap to close, before a single new feature gets added.