Building a SaaS Product for Low-Connectivity Markets: What Actually Works

I once watched a sales rep in Multan try to sync 142 orders over a 2G signal at 11pm. He'd been offline for nine hours. The app froze. He restarted. It froze again. He went to sleep and his manager called me the next morning, furious.

That was the moment I understood the gap between SaaS built in San Francisco and SaaS that actually has to work in Sukkur, Surabaya, or Sokoto.

Most product teams design for the 95th percentile of connectivity and then bolt on an "offline mode" later. It doesn't work. You can feel it the second you ship to a market where the median user spends 40% of their working day in dead zones. The whole architecture has to be inverted. The cloud isn't the source of truth anymore — the device is. Sync is the feature, not an afterthought.

Here's what I've learned the hard way building for these markets.

Architecture: the database lives on the phone

If you're building offline first SaaS architecture, your first big decision is where state lives. The honest answer is: on the device, and the server is a replica.

That sounds simple. It's not. It changes how you think about IDs (UUIDs, never auto-increment), conflict resolution (last-write-wins is lazy and will burn you), audit trails (timestamps from a device clock are unreliable — users change them), and even your pricing model (because data volumes per user balloon).

A few things I'd tell my past self:

• Pick a sync engine before you pick a framework. We went the other way and rewrote twice. WatermelonDB, RxDB, PowerSync, Couchbase Lite — they all have tradeoffs, but pick one and commit.
• Treat every API call as eventually-consistent. If your backend assumes a request will arrive in 200ms, you're already broken. Some of ours arrive 6 days late, from a rep who took unpaid leave and finally opened the app on a bus.
• Compress aggressively. Not just gzip — actual payload design. We cut one sync payload from 380KB to 41KB by removing redundant nested objects and shipping diffs instead of full records. On a 2G connection that's the difference between a 4-second sync and a 90-second timeout.
• Build a queue, then build a queue for the queue. Retries, exponential backoff, dead letters, manual replay tools. Boring infrastructure. Saves your support team.

When we were building Zivni, our field sales platform for FMCG teams, we assumed 30% of users would be offline at any given moment. The real number turned out to be 61% during peak market hours. Distributors operate in basements, warehouses, rural towns. The signal map of a country and the sales map of a country are not the same map.

UX: assume the user is tired, hot, and holding a cheap phone

Look, I've sat with field reps in 44°C heat trying to log an order while a shopkeeper yells at them about pricing. That's the real testing environment. Not your office.

A few UX rules I'd defend in a fight:

Loading states must lie a little. If a button shows a spinner for more than 2 seconds, users tap it again. And again. You'll get duplicate orders. Show immediate optimistic confirmation, then reconcile silently. "Saved" should appear instantly even if the actual sync happens 6 hours later.

Forms should remember everything, forever. If a rep starts filling an order, gets interrupted, closes the app, reopens it on a different device three days later — that draft should still be there. Drafts are sacred. We've had reps lose 40-minute order entries because of a battery death, and they don't forgive you for that.

Reduce taps. Then reduce them again. Our V1 order screen had 11 taps to log a standard order. V4 has 3. The retention curve looked completely different.

Default to the most common answer. If 73% of orders for a given SKU are quantity 6 (one carton), default to 6. Don't make the user type it. This sounds obvious. Almost no SaaS does it.

Voice and photo over typing. Cheap Android keyboards are painful. A photo of a competitor's shelf is worth more than a 200-character text field nobody fills in.

Go-to-market: the buyer isn't who you think

Here's the thing about software for emerging markets — the person who pays isn't the person who uses it, and neither of them speaks the same language about value.

The HQ buyer wants dashboards, compliance, retention metrics. The regional manager wants reps to stop lying about visits. The rep wants the app to not crash and ideally help him earn more commission. If you only sell to one of these three, you lose.

I got this wrong at first. We sold hard to HQ, won the contract, and then watched adoption die in the field because reps hated the app. Now we run a parallel motion: a top-down enterprise sale and a bottom-up field pilot, simultaneously. Two different demos. Two different value props. Same product.

A few other go-to-market things that surprised me:

Pricing in local currency, billed monthly, matters more than discounts. A $40/user/month tool feels like nothing in Dubai and impossible in Karachi. Tier by geography or you'll get arbitraged.

Training videos in regional languages — not English with subtitles — moved our activation rate by something like 28 percentage points. Urdu, Hausa, Bahasa, Tagalog. WhatsApp-friendly file sizes. Under 90 seconds each.

And references travel. A distributor in Lahore will trust another distributor in Faisalabad more than any case study you write. Build the customer network, then get out of its way.

What I'd do differently

If I were starting over tomorrow I'd spend the first 90 days not writing code. I'd sit with 30 users in 6 cities. I'd watch them work. I'd note every place the signal drops, every time they curse at a screen, every workaround they've built in a paper notebook.

Then I'd design the sync engine. Then the data model. Then — only then — the UI.

Most SaaS founders do this in the opposite order. That's why most SaaS built for emerging markets quietly dies in year two, after the pilot money runs out and the real usage data comes in.

The opportunity is huge. The next billion SaaS users aren't on fiber. They're on a patchy 4G connection in a market stall, and they're waiting for someone to build software that respects that reality.

Are you building for them, or for yourself?