Building for low-bandwidth reality
Device and network assumptions that hold in London quietly break the experience for real customers elsewhere.
Lane Steiner
Engineering Manager
The default that doesn't travel
A lot of software is built for a fast phone on a good network. That assumption is invisible until it meets a mid-range device on an intermittent connection — and then it's the whole experience. For the customers a lot of African enterprises actually serve, that's not the edge case. It's the default.
What we change
We budget payload sizes the way we budget latency. We design for offline-first where it matters, retry on flaky connections, and test on the devices people actually carry — not just the flagship on the engineer's desk. None of it is exotic. It's a set of defaults that assume the network will let you down and the device won't be new.
Why it pays off
Build for the constrained case and the comfortable case comes free. The reverse is never true. A system that holds up on a weak network and an older phone is a system that holds up everywhere — and that's the only kind worth shipping into production that touches hundreds of millions of people.
Related Articles
More notes from the team — on how we build, what we measure, and the calls we make along the way.
