"It Works on WiFi" Is Not Working

Every developer has shipped something that flew in the office and crawled in the field. In East Africa, the gap between those two environments is where software goes to die.

The user in Kariakoo on congested 4G, the school bursar in Morogoro on 3G, the driver whose connection drops between towers — these aren't edge cases. They're the median user. We build for them first, and treat the fiber-connected office as the edge case.

What real conditions look like

• Bandwidth that swings from decent to dial-up within a minute
• Latency to European servers of 200–600ms — before your API does anything
• Connections that drop mid-request, mid-upload, mid-payment
• Data bundles that make every megabyte a cost the user feels
• A long tail of low-RAM Android phones running old browser versions

Design for that reality and your software feels magical everywhere. Design for WiFi and it feels broken almost everywhere that matters.

The principles we build by

Ship less JavaScript

Every framework megabyte is seconds of loading and shillings of data. We render on the server by default, send HTML, and hydrate only what genuinely needs interactivity. A dashboard that ships 300KB instead of 3MB isn't a nice-to-have — it's the difference between used and abandoned.

Put the server near the user

Hosting in Frankfurt because the tutorial did is a 300ms tax on every single request. Edge platforms and African regions have changed the math — our own site and products run on edge infrastructure so the first byte arrives fast in Dar, not just in demos.

Make every request survivable

Assume any request can fail halfway:

• Idempotent writes — retrying a payment submission must never charge twice.
• Optimistic UI with reconciliation — record the action locally, sync when the network returns.
• Explicit failure states — "Saved, will sync when online" beats a spinner that never resolves.

Compress everything, cache aggressively

Images sized to the actual screen, WebP or AVIF by default, immutable assets cached forever, HTML revalidated cheaply. The fastest request is the one the phone never has to make.

Test on the real thing

Chrome DevTools throttling is a rough sketch. At least once per release, someone on the team uses the product on an actual budget Android phone with an actual mobile bundle, ideally outside the city. It's humbling every time — and it's where the real bug list comes from.

Performance isn't a feature in this market. It's the price of admission.

The business case

Slow software here doesn't just annoy — it costs directly. Staff wait, customers give up, and every wasted megabyte is money your users paid for. When we rebuilt one client's workflow with these principles, task completion time didn't drop by percent — it dropped by minutes per task, multiplied across every employee, every day.

The takeaway

You can't control the network. You can control how gracefully your software degrades when the network has a bad day — and in our market, the network has a bad day every day, somewhere.

Build for the user in the field, and the user in the office gets a great experience for free. Build for the office, and you've built for almost no one.

Building for East African users? That's literally our specialty — say hello.