Building for Emerging Markets: Connectivity, Payments, and Mobile-First in Southeast Asia

Mobile-first in Southeast Asia is not a responsive breakpoint

If you built a marketplace for an urban, card-carrying, fast-fibre user and you are now watching drop-off spike as you push into the Philippines, Indonesia, or Vietnam, the problem is rarely your feature set. It is that the product silently assumes a device, a network, and a payment method that most of your new users do not have. The fix is not a coat of responsive CSS. It is treating budget Android, unstable mobile data, and fragmented local payment rails as first-class engineering constraints from the data model up.

Here is the short version, then the detail. Keep the client thin and push rendering and logic to the server. Make every critical flow tolerate a mid-session connection drop. Integrate the dominant local e-wallet per country before you touch cards. And test per market, because a single Southeast Asia configuration underperforms in every individual market you apply it to.

We have built and operated property marketplaces, Lamudi and LISTD, live under these exact conditions: buyers on hand-me-down Android phones, agents uploading listing photos over patchy data, and users who expect to pay through GCash or over the counter, not a Visa card. What follows is what actually broke and what we changed.

Design for budget Android, not the newest iPhone

The regional device mix is dominated by entry-level Android handsets with 2 to 3 GB of RAM and low-end chipsets. That single fact constrains almost every client-side decision you make.

On those devices, a heavy JavaScript bundle does not just load slowly, it janks scrolling, drops frames on image-heavy lists, and gets killed by the OS when memory pressure rises. Your listing grid, the most-used screen in any property marketplace, is exactly the surface that suffers most.

Practical implications:

• Budget your JS aggressively. Every dependency is memory and parse time on a device that has little of either.
• Virtualize long lists so a result set of hundreds of listings does not hold hundreds of DOM nodes and decoded images in memory at once.
• Lazy-load and downscale images hard. A full-resolution hero photo is a memory spike, not a nicety.
• Prefer server-rendered HTML for content-heavy screens so the device paints without first parsing and executing a large client app.

Connectivity is the product, not a channel

In several SEA markets, more than one in five smartphone users reach the internet only over mobile networks, with no fixed-broadband fallback. Mobile network quality is not a secondary channel for those users. It is the entire experience.

And the connection is not stable. A user in Metro Manila can move between strong LTE and congested 3G several times inside one session, including mid-checkout. Any flow that assumes a stable, fast link (upload, real-time search, payment) will fail for a meaningful slice of users unless it degrades gracefully.

That reframes the engineering target. You are not designing for slow but steady 3G. You are designing for a connection that fluctuates and occasionally vanishes for seconds at a time. This is not an edge case at the global scale either: 2G still reaches the overwhelming majority of the world's population and well over a billion people live beyond reliable 3G or 4G, so a genuine degraded mode is table stakes for emerging markets, not a nice-to-have. Concretely:

• Make payment and upload flows resumable and idempotent, so a dropped connection retries instead of double-charging or losing a half-finished listing.
• Persist form and session state locally, so a reload after a drop does not throw the user back to step one.
• Ship a genuine degraded mode, not just a spinner: cached results, queued actions, and clear offline feedback.

This is where core marketplace architecture has to be adapted rather than reused. The search, listing, and messaging decisions in a two-sided property marketplace all change shape once you assume the network is hostile.

Payments are local, not universal

There is no single Southeast Asia payments module. A Philippines integration and an Indonesia integration are two different rail sets, and getting this wrong is the fastest way to lose a transaction you already earned.

Start with the dominant local e-wallet for the specific country, then add the national QR standard where one exists. Treat cards and cash on delivery as secondary. Cash on delivery is in structural decline across the region, falling from roughly half of e-commerce payments in 2019 to under a third by early 2026, dragged down by high return and failure rates. Cards stay low outside urban segments.

National QR standards are a quiet win for engineering teams. QRIS in Indonesia, PromptPay in Thailand, and VietQR in Vietnam each unify many banks and wallets behind one scannable code, which cuts the number of discrete integrations you maintain per country. Payment choice is also a trust decision in these markets, so treat it alongside the rest of your trust and safety work rather than as a checkout afterthought.

Build, buy, or defer: what this actually costs you

The honest first question is not how to build all of this. It is whether you need it yet, and where to spend first.

You need it the moment you are genuinely acquiring users on budget Android over mobile data who pay through a local wallet. If you are still validating in an urban, card-carrying, fibre-connected segment, some of this is premature: build the degraded modes when the traffic that needs them shows up, not before. What is never premature, even at MVP, is two things: a payment rail your users actually hold, and payment and upload flows that survive a dropped connection. Get those wrong and you lose transactions you already earned, which no amount of later optimization recovers.

On payments specifically, build versus buy is the decision that matters most, and buy usually wins early. Integrating GCash, Maya, or an Indonesian wallet set directly means separate onboarding, compliance, settlement, and reconciliation per rail, repeated per country. A payment aggregator (dLocal, Xendit, HitPay, and similar) collapses many of those into one integration and one settlement relationship, in exchange for a cut and less control. For most marketplaces entering a new market, that trade is worth it: you buy speed and coverage now and revisit direct integration only when volume makes the fee material.

The cost of the connectivity and device work is a different shape. It is not a line item you buy, it is discipline you spend across the whole build: a JS budget you refuse to blow, an image pipeline you actually operate, resumable flows, and per-market testing. The expensive version is retrofitting all of that into a Western-first codebase after launch, which is why treating it as design-time architecture is the cheaper path even though it feels slower at the start.

The failure modes are predictable. Teams over-integrate payments before they have volume, ship a spinner and call it a degraded mode, test on office laptops and fast wifi, and discover the real device and network conditions only from the drop-off dashboard. Each is avoidable by deferring the right things and refusing to defer the two that are non-negotiable.

Borrow lite-app architecture, then adapt it

The lite-app playbook is well proven. Facebook Lite shipped as a sub-1 MB app by moving layout and business logic to a thin, server-driven client and cutting animations and heavy UI. Twitter Lite, built as a PWA, reportedly used far less data than the native app while keeping offline support and push. The core pattern (thin client, server-side rendering, aggressive compression) transfers directly to a marketplace's search and listing screens.

But do not copy it wholesale. A social feed mostly moves text and small media in one direction. A marketplace adds structured search, image-dense listing pages, two-way messaging, and payment flows, and each of those has to be optimized independently.

The marketplace-specific tradeoffs

This is where the real decisions live, because you cannot strip a marketplace down as far as a feed and still have a marketplace.

Listing images are the obvious pressure point. Photos drive lead conversion, so you cannot simply drop them, but full-resolution sets destroy budget devices and slow connections. The answer is disciplined delivery: modern formats, per-connection sizing, and lazy loading, handled in a real image pipeline rather than by shipping originals.

Search and filter payloads are the next one. A rich, faceted filter UI is cheap on fibre and expensive on 3G. Keep the payload lean, paginate server-side, and avoid re-fetching the world on every filter tap.

Maps deserve special caution. A live map view is one of the most bandwidth-heavy and battery-heavy surfaces you can ship, so on budget devices and weak connections it should load on demand rather than by default, with a list view as the lighter primary path.

Messaging between buyer and seller must tolerate the same fluctuating network. Queue outbound messages, show honest delivery states, and reconcile when the connection returns.

One asymmetry matters in property specifically: the two sides often have different devices. Agents and sellers may have better phones and connectivity than buyers, so the buyer-facing surfaces deserve the harder optimization budget.

Test and ship per market, not per region

Network reality is not uniform, so neither is your performance target. Real-world conditions differ sharply: one market may see roughly 10 Mbps down and 80 ms latency while another sits nearer 5 Mbps, 150 ms, and measurable packet loss. A single regional target is wrong on both ends.

• Set device and network budgets per market, tied to representative low-end handsets and throttled profiles, not to your office laptop.
• Emulate packet loss and mid-session drops in testing, not just low bandwidth.
• Measure the flows that earn money (search, listing view, contact, pay) on those profiles, not just synthetic lab runs.

What we learned building Lamudi and LISTD

The recurring lesson is that emerging-market constraints are architectural, not cosmetic. You cannot bolt them on after a Western-first build. Deciding what to strip from a listing page on a weak connection, which payment rail actually mattered in a given market, and how to keep a two-sided product usable when one side is worse-equipped than the other are all design-time calls, not late polish.

If you already have a live marketplace straining under these conditions, you do not necessarily need a rewrite, but you do need to be honest about whether to retrofit or rebuild. That is the same judgment we bring to any rebuild-or-refactor decision: fix the highest-leverage constraints first, keep the layers separable, and let the market you are actually serving, not the one your original stack assumed, set the target.