EdTech in Emerging Markets: Why Our 'Mobile-First' Design Was Actually Desktop-First in Disguise

vp_eng_keisha · February 23, 2026, 5:55pm

I need to share a humbling lesson we learned expanding our EdTech platform to Southeast Asia and Latin America.

We thought we were building “mobile-first.” We were wrong.

The Context

VP of Engineering at an EdTech startup. We’re growing fast in the US and decided to expand internationally to Southeast Asia and Latin America.

We’d always said we were “mobile-first” because we designed responsive layouts and tested on phones. Our usage data showed 75% mobile, 25% desktop. We felt good about our mobile strategy.

We were fooling ourselves.

The Wake-Up Call

When we launched in the Philippines and Brazil, students tried to use our app. And they couldn’t - not really.

Here’s what we didn’t understand:

Students were using:

3-5 year old Android phones (not flagship devices)
Spotty 3G connections (not 5G or even reliable 4G)
Limited data plans (500MB-2GB per month)
Areas with frequent power outages

Our app:

Required 2.3MB initial download
Used heavy JavaScript frameworks
Loaded high-resolution images
Relied on real-time sync
Took 12 seconds to load on 3G

One student told us: “I can’t afford to use your app. It uses all my data.”

That hit hard.

What We Got Wrong

We thought “mobile-first” meant:

Responsive design
Works on phones
Touch-optimized UI

But real mobile-first means:

Offline-first architecture
Data-conscious design
Progressive enhancement
Works on slow networks
Works on old devices
Considerate of battery and data costs

We’d designed for San Francisco mobile users (5G, unlimited data, latest iPhones), not for the students we were trying to serve.

The Redesign

We had to fundamentally rethink our approach:

1. Aggressive Optimization

Bundle size: 2.3MB → 450KB (80% reduction)
Code splitting: Load only what’s needed
Lazy loading: Images load on scroll
Cached content: Works offline for 2 weeks
Compression: Aggressive asset compression

2. Offline-First Architecture

Local-first data with sync when online
Queued operations (save, submit, post)
IndexedDB for substantial local storage
Service workers for asset caching
Graceful degradation when offline

3. Data-Conscious Design

Smaller images, better compression
Load low-res first, high-res on demand
Minimal real-time features
Batch sync instead of constant polling
User-visible data usage indicators

4. Progressive Enhancement

Works on 2G, good on 3G, great on 5G
Basic functionality without JavaScript
Enhanced features for capable devices
Adaptive quality based on connection

The Results

After 4 months of redesign:

Performance:

Load time on 3G: 12s → 3s
Data usage: 80% reduction
Works offline: 2 weeks of content cached
Battery impact: Significantly reduced

User Feedback:
“Now I can actually use it without running out of data.”
“It works on the bus when connection is bad.”
“I can study even when the power is out.”

Business Impact:

Engagement up 3x in emerging markets
Retention improved significantly
Word-of-mouth growth increased
Negative reviews about performance dropped to near zero

The Leadership Lesson

Here’s what I learned as an engineering leader:

Mobile-first is a mindset, not just media queries.

Real mobile-first means designing for the worst-case mobile scenario:

Oldest devices still in use
Slowest networks your users experience
Most expensive data plans
Least reliable power
Most constrained resources

Then enhancing for better conditions.

The Diversity Factor

Our team was entirely US-based. Silicon Valley engineers with unlimited data, fast WiFi everywhere, flagship devices.

We literally couldn’t imagine the constraints our users faced.

The solution? We hired engineers from our target markets. Within weeks of having team members from the Philippines and Brazil, our entire perspective shifted.

Diverse teams build better products for diverse users. This isn’t just feel-good diversity rhetoric - it’s a product quality issue.

What This Means for Your Product

Ask yourself:

What devices are your actual users using?
What network conditions do they experience?
What data costs do they face?
Have you tested on 3-5 year old devices on 3G?

If you’re only testing on your MacBook Pro and iPhone 15 on fast WiFi, you’re not testing mobile-first.

The Question for This Community

How many of us are truly building mobile-first vs building desktop web that happens to work on phones?

Are we designing for the mobile users we have, or the mobile users we imagine?

I’d love to hear from others who’ve dealt with emerging market constraints or truly mobile-first architecture. What did I miss? What else should we consider?

Keisha

mobile_maria · February 23, 2026, 5:55pm

Keisha, this resonates SO deeply with my experience at Uber. Everything you described, I’ve lived through in our São Paulo and emerging markets work.

Validating Your Experience

You’re absolutely right. The quote “I can’t afford to use your app” - we heard that exact same feedback in Brazil, India, and Southeast Asia.

That 12% battery drain difference I mentioned in another thread? In regions where people might not have reliable power for charging, that’s the difference between your app being essential and your app being deleted.

The Technical Details You Nailed

Your optimization numbers are impressive and exactly what we’ve seen work:

Bundle Size: 2.3MB → 450KB
This is the kind of aggressive optimization that actually matters. Every KB counts on metered connections.

Offline-First Architecture
This is critical. You mentioned IndexedDB and service workers - that’s exactly right. Here’s what we’ve learned:

Offline Architecture Patterns

1. Local-First Data Model

2. Smart Sync Strategy

Don’t sync in real-time, batch operations
Sync only deltas, not full state
Compress sync payloads
Allow users to control when heavy syncs happen (“Sync now” vs “Sync on WiFi only”)

3. Progressive Data Loading

Critical data first (what user needs now)
Nice-to-have data later (background, when bandwidth available)
Heavy assets only on WiFi (configurable by user)

What We Added That You Might Find Useful

Network-Aware Design
Show users their connection quality and let them make choices:

“You’re on 3G. Download high-quality video now or wait for WiFi?”
“Large update available (45MB). Download on WiFi only?”

Users appreciate being in control of their data usage.

Adaptive Quality

Images: Different resolutions based on connection speed
Video: Adaptive bitrate streaming
Features: Disable real-time features on slow connections
Assets: Serve WebP on supported browsers, optimized JPEGs elsewhere

Data Usage Dashboard
Show users how much data the app has used. Transparency builds trust.

Technical Recommendations

For React Native/Flutter Apps:
Consider using SQLite instead of just AsyncStorage for complex offline data. Better performance and more reliable.

For Web Apps:
IndexedDB + service workers like you’re doing. Add BackgroundSync API for reliable sync when connection returns.

Testing Tools:

Chrome DevTools network throttling (but test on real devices too)
BrowserStack/Sauce Labs for real device testing
Set up test devices in your target regions

The Real Device Testing Point

You can’t test emerging market performance from San Francisco on your MacBook. We maintain:

Test devices that match our user demographics (3-5 year old Androids)
VPN connections to test from different regions
Real SIM cards from target markets to test actual network conditions

It’s more expensive but essential.

The Diversity Point - So Important

Your point about hiring engineers from target markets is CRUCIAL. This isn’t just diversity for diversity’s sake - it’s product quality.

When we opened our São Paulo office, the engineers there immediately identified issues we’d never considered:

Battery drain (power outages common)
Data costs (metered plans, expensive)
Device performance (older phones)
Network reliability (spotty coverage)

You can’t design for users you don’t understand. And you can’t understand users you’ve never been.

Sharing Uber’s Open Source

We’ve open-sourced some of our offline-sync infrastructure. I’ll share links in a follow-up (don’t want to self-promote in the main thread), but there are patterns for:

Optimistic UI updates
Conflict-free replicated data types (CRDTs)
Operation queuing and replay
Network-aware request strategies

The Bigger Question

Your final question: “How many of us are truly building mobile-first?”

I’d say less than 20% of companies are actually mobile-first in the way you’re describing. Most are “mobile-compatible” at best.

True mobile-first means:

Test on worst-case devices first
Design for data scarcity
Offline is not an edge case, it’s expected
Performance budgets enforced
Progressive enhancement not graceful degradation

Thanks for sharing this. More teams need to hear this message.

Maria

alex_dev · February 23, 2026, 5:56pm

Keisha, this is humbling to read as a developer who’s always worked in San Francisco with fast internet and good devices.

The Privilege I Didn’t Recognize

I literally never considered data costs or device age as constraints. Unlimited data plan, latest MacBook Pro, WiFi everywhere.

When I test “mobile,” I open Chrome DevTools responsive mode and resize the browser. Maybe pull out my iPhone if I’m being thorough.

That’s not mobile-first. That’s desktop-pretending-to-be-mobile.

The Questions This Raises

1. Testing on Slow Networks
You mentioned Chrome DevTools network throttling isn’t enough. What tools do you recommend for accurately testing on real 3G/2G conditions?

2. Target Device Testing
Should developers literally buy old Android phones to test on? How do I know which devices my users actually have?

3. Data Usage Measurement
How do you measure how much data your app uses? Is there a tool that tells you “this feature costs users X MB per use”?

The Learning Moment

Your story about the student saying “I can’t afford to use your app” really hit me.

I’ve never had to think about affording to use an app. My constraint is time, not money or data. That’s massive privilege that shapes how I build.

Practical Question

For someone who wants to build more consciously for real mobile users (not SF mobile users), what’s the action plan?

Buy a 3-year-old Android phone for testing?
Set up network throttling (better tools than DevTools)?
Test from different geographic locations?
What else?

I want to do better, but I honestly don’t know where to start beyond “make things faster.”

Thanks for sharing this. It’s opened my eyes to blind spots I didn’t know I had.

Alex

maya_builds · February 23, 2026, 5:56pm

Keisha, this changes how I think about design systems. The implications for component libraries are huge.

Design System Implications

If we’re truly designing mobile-first for emerging markets, our design systems need to fundamentally change:

Image Components

Traditional approach:

High-res images by default
Lazy loading as optimization

Data-conscious approach:

Low-res placeholder first (like 10KB blurred image)
Progressive loading based on connection
User control: “Load high-quality images?”
WebP format with fallbacks
Aggressive compression built-in

Loading States

Traditional approach:

Spinner or skeleton
Assumes fast loading

Offline-first approach:

Cached content shown immediately
“Syncing…” indicators
“Last updated: 2 hours ago” timestamps
Clear offline vs online state
Queue indicators (“3 actions pending sync”)

Icon Systems

Traditional approach:

Icon fonts or SVG sprites
Hundreds of icons loaded

Data-conscious approach:

Only load icons actually used on the page
Inline critical icons
Lazy load decorative icons
File size budget per page

The Design Token Challenge

When you reduce bundle size from 2.3MB to 450KB, that affects design decisions:

Typography:

Fewer font weights loaded
System fonts as fallbacks
Variable fonts (one file, multiple weights)

Colors:

Smaller palette = smaller CSS
Design tokens optimized for size

Animations:

CSS animations over JavaScript
Respect prefers-reduced-motion
Disable on slow connections

The Question I Have

How did your team adjust the design system for data constraints?

Did you:

Build a “lite” version of components?
Add data-aware variants?
Completely redesign components?

And how did designers react? This requires fundamentally different design thinking.

Accessibility Intersection

There’s an interesting intersection with accessibility here:

Data-conscious design IS accessible design:

Works on older devices
Works on slow connections
Respects user preferences
Progressive enhancement
User control over resources

Making apps work for emerging markets makes them better for everyone, including users with disabilities or older devices in developed markets.

The Storybook Challenge

How do you document and demonstrate data-conscious components in Storybook?

Do you need:

Different stories for different connection speeds?
Data usage indicators per component?
Performance budgets enforced in preview?

What I’m Working On

This conversation is making me rethink our design system. I’m going to add:

Data budget indicators:
Show designers how much data each component costs

Connection-aware variants:
Components that adapt to connection speed automatically

Offline state designs:
Every component needs an offline state design

Thanks for this perspective. It’s changing how I think about design systems fundamentally.

Maya

product_david · February 23, 2026, 5:56pm

Keisha, this is a masterclass in product strategy for global markets. The business implications here are massive.

The Market Opportunity Angle

Here’s what strikes me from a product perspective:

Emerging markets are growth markets. If your product doesn’t work there, you’re missing the biggest growth opportunity.

But most products are built for SF/NY/London, then “adapted” for the rest of the world as an afterthought.

The Strategy Flip

What if we flipped the approach?

Design for emerging markets first, then enhance for developed markets.

Progressive enhancement instead of graceful degradation:

Works on 3G → Baseline experience
Works on 4G → Enhanced features
Works on 5G → Delightful extras

This ensures the product works everywhere, then gets better with better conditions.

Competitive Dynamics

Your story illustrates something critical: Data-heavy apps lose to lighter local competitors in emerging markets.

In India, Indonesia, Brazil - local companies build lighter, faster apps because they understand local constraints. Western companies show up with 100MB apps and wonder why adoption is low.

You can’t win markets you don’t design for.

How This Affects Product Roadmap

If I’m a product leader considering emerging market expansion:

Wrong Approach:

Build for US market
Achieve product-market fit
“Expand internationally”
Struggle with adoption
Blame “cultural differences”

Right Approach:

Design for worst-case constraints (emerging markets)
Add progressive enhancements for better conditions
Product works everywhere from day one
Competitive advantage in both emerging and developed markets

The ROI Question

What’s the business case for this level of optimization?

Your results speak volumes:

Engagement up 3x
Retention improved significantly
Word-of-mouth growth
Negative reviews dropped

But what’s the investment required?

Cost Side:

4 months of engineering time
Hiring engineers from target markets
Testing infrastructure for real devices/networks
More complex architecture (offline-first)

Benefit Side:

Access to massive markets (billions of users)
Better product for everyone (fast is good everywhere)
Competitive moat (hard to replicate)
Word-of-mouth growth

For a growth-stage company, this seems like a no-brainer investment.

The Question for Leadership

How did this affect your product roadmap and prioritization?

Did you:

Pause feature development for 4 months to optimize?
Run optimization in parallel with features?
Dedicate a specific team to emerging markets?

And how did you make the business case internally? What metrics convinced leadership this was worth the investment?

Market Expansion Strategy

For other product leaders considering this:

Don’t think of emerging markets as “nice to have” expansion. Think of it as:

Largest addressable market
Competitive differentiation
Product quality improvement
Long-term strategic positioning

The companies that win globally are the ones that design globally from the start.

Thanks for sharing the real numbers and honest lessons. This is product strategy gold.

David