Building Mobile Apps for Emerging Markets

I spent a week in India in February working with a client building logistics software for last-mile delivery. Their drivers use devices that cost roughly $80. Network connectivity is 3G at best, sometimes 2G. The app I'd designed for my MacBook wouldn't install on half their fleet.

That conversation forced a reckoning. If you're building for emerging markets—India, Southeast Asia, Africa—you're not optimizing for the latest flagship phone and fiber-fast networks. You're optimizing for constraint. And constraint changes everything about how you design.

The emerging market mobile opportunity is real. Growth is there. But the pattern I see from most Western startups is: build the product for US conditions, then try to make it work in emerging markets. That's backwards. You need to start with constraint.

The Hardware Ceiling

The median smartphone in India in 2022 is a Realme or Poco device with 3-4GB RAM and an entry-level ARM processor. In Southeast Asia, similar story. In Africa, you're looking at even older hardware on some markets.

Most React Native apps sit at 50-120MB uncompressed. On a device with 32GB storage, that's manageable. But when you're talking about a 128GB device that costs $80 and is shared by family members, every MB matters.

I've seen teams dismiss this. "Users will delete photos if they need space." Sure. But you're now asking users to actively manage their phone to use your app, which is a friction cost you're introducing.

Flutter does better here because it compiles to native code and the resulting binaries tend to be leaner, but even Flutter apps balloon if you're not intentional. The pattern doesn't matter; the principle does. Size is a feature in emerging markets.

But size is just the visible constraint. Network is the real problem.

Network is a Design Constraint

When you design for users on fiber or 4G, you design for instant feedback. You design assuming round-trip latency under 100ms. You design for real-time sync.

When you design for 3G—which can have 1-2s latency—those assumptions break. You need offline-first architecture. You need request batching. You need to rethink what "real-time" even means.

I watched our client's delivery app fail during field testing because it was making 40 HTTP requests to load a delivery list. Each request was waiting for a response before the next started. On 4G with 50ms latency, that's 2 seconds. On 3G with 200ms latency, that's 8 seconds. Drivers watched a loading spinner for longer than the task took.

We restructured the data layer: batch requests, pre-fetch data that's likely to be needed, cache aggressively. Suddenly the same operation worked on 3G with acceptable performance.

That's not a technical trick. That's a fundamental shift in how you think about app architecture. You're not optimizing for perfect data synchronization anymore. You're optimizing for good-enough offline availability.

Rethinking Feature Design

The hardest part of building for emerging markets isn't technical. It's saying no to features.

When you have fiber and 4G, you can load images, embed videos, use high-resolution assets, do complex animations. It works, and users expect it. But on 3G? That video that loads instantly at headquarters loads for 30 seconds in the field.

We built a version of our client's app with rich media, thinking the UX would be better. It wasn't. It was slower and more frustrating. We stripped it down: lower-resolution images, no autoplay video, text-heavy interface. The UX got better.

That's not a compromise. It's a better design for the actual constraints of the market.

The same applies to interactions. Animations that feel snappy on a 4GB RAM flagship feel laggy on a 2GB device. Complex forms with live validation create a sense of slowness because the processor is strained. Simplification is acceleration.

The broader insight: emerging market design teaches you something valuable. It teaches you what's actually essential. Features that feel critical in the boardroom often turn out to be noise when you strip away the infrastructure that made them possible.

The Economics Unlock

When you build for emerging markets properly, the unit economics change. Lower data usage means lower infrastructure costs. Smaller binaries mean lower app store bandwidth. Simpler feature sets mean lower development and support costs.

We're seeing this in our work. A delivery logistics app built for constraint is cheaper to operate and easier for drivers to use than a feature-rich app built for Western markets.

But the real unlock is reach. There are 1.8 billion smartphone users in India alone. Most of them don't have access to apps built for high-end infrastructure. If you can build for their constraints, you're not optimizing a niche. You're opening a market that most Western software ignores.

Where the Opportunity Is

March 2022, I'm seeing founders in three categories:

The first treats emerging markets as "nice to have." They build for the US, then spin up a "lite" version. That rarely works because the lite version is a second-class experience.

The second builds natively for emerging markets from day one. They start with constraint as a design principle. They accept that this means different architecture and different feature tradeoffs. Their app works brilliantly on 3G and looks good on Western infrastructure too.

The third is still building for the US and complaining about emerging market performance. They'll be forced to reckon with this soon.

The market is moving. Devices are getting cheaper, but network expansion is inconsistent. Users in emerging markets are willing to pay for software that actually works for them. But work means respecting their constraints, not fighting them.

If you're serious about emerging markets, start there. Design for 3G, not as a degraded experience, but as the baseline. Build for 2GB RAM as the design target. Treat every MB and every millisecond as something you're borrowing from users.

That mindset doesn't just make you succeed in emerging markets. It makes you better everywhere.