There’s a version of “mobile-first” that means a layout collapses neatly to one column on a small screen. That’s not the version that matters here. In Kenya, mobile-first is a set of physical constraints: a mid-range Android device, a data bundle the user is actively rationing, a network that drops between 4G and EDGE on the same matatu ride, and a screen being read in direct equatorial sunlight.

Design that ignores those constraints doesn’t fail loudly. It fails quietly — in the bounce rate, in the abandoned form, in the support email that says “the site won’t load.” After several years of shipping products for East African users, here is what consistently moves the needle.

Weight is a feature, not an afterthought

Every kilobyte you ship is money out of someone’s data bundle. We treat page weight as a first-class budget, not something to “optimize later”:

  • Ship images in modern formats and the right size. A hero image served as a 1.2 MB PNG is a design decision to charge your user. WebP at the displayed resolution, served from a CDN edge close to Nairobi, is usually 80–90% smaller for the same perceived quality.
  • Default to system and variable fonts. A single well-chosen typeface beats a four-weight custom stack the user pays to download before they read a word.
  • Send less JavaScript. The single biggest performance lever on mid-range Android isn’t network — it’s the CPU cost of parsing and executing JS. A statically rendered page that hydrates only what’s interactive will always feel faster than a SPA that boots the whole app to show a paragraph.

Design for the network you have, not the one you wish for

Assume the connection will drop. Then design as if that’s normal:

  1. Server-render the content. The text, the offer, the contact number — they should be in the HTML, visible before a single script runs. If your “above the fold” depends on a JavaScript round-trip, a flaky connection hides your entire value proposition.
  2. Make forms forgiving. Preserve input across reloads. Validate inline. Never make someone re-enter a phone number because a request timed out.
  3. Cache aggressively and immutably. Versioned, long-cached assets mean a returning visitor pays the data cost once, not every visit.

Sunlight, thumbs, and the real device

The lab is a lie. The real test happens outdoors, one-handed, on a cracked screen:

  • Contrast for daylight. Subtle grey-on-grey looks elegant on a calibrated monitor and disappears entirely on a phone in the sun. We push contrast harder than a Western design review might suggest — and we test outside.
  • Thumb-reachable actions. The primary action belongs in the bottom third of the screen where a thumb naturally rests, not stranded in a top corner.
  • Generous tap targets. 44 px minimums aren’t a nicety; they’re the difference between a booked appointment and a mis-tap.

Language and trust travel together

Adoption doubles when the interface meets people where they are. For one agritech client, shipping the advisory flow in Swahili — not as a toggle buried in settings, but as the default for the counties they served — was the single change that moved pilot adoption most. Trust signals matter just as much: a real phone number, a physical Nairobi location, and an M-Pesa-shaped payment flow do more for conversion than any amount of polish.

The takeaway

Designing for the African mobile web isn’t about doing less. It’s about spending your bytes, your CPU cycles, and your user’s attention where they actually count. Build the content into the HTML, keep the payload honest, design for sunlight and thumbs, and speak the user’s language by default. Do that, and the product stops feeling like it was built for somewhere else.

That’s the standard we hold ourselves to on every engagement — and it’s why we reach for static rendering, edge delivery, and ruthless payload budgets before we reach for the latest framework.