Build for the user on one bar of signal
Most software is designed in conditions its users will never have. Here's what changes when you design for the real ones.
I’ve built a lot of software for people who are moving. Delivery riders, truck drivers, dispatchers, field agents. People who open an app while a matatu cuts them off, while they’re standing in a metal-roofed yard that eats their signal, while their phone is at 12% and has been working since 6am.
That user changed how I build everything.
The lie of the dev machine
Here’s the uncomfortable part. Most software gets designed and tested in the best conditions it will ever see. A fast laptop. Office wifi. A fresh, expensive phone. The developer’s reality is the 1% case — and we ship it to the 99% as if it’s normal.
Then a real person opens the app on one bar of signal, and it spins. And we call them an edge case.
They are not the edge case. They are the case.
If it doesn’t work on a patchy connection in a real city, it doesn’t work. The rest is a demo.
What actually changes
When you take that seriously, a pile of decisions stop being optional.
- Offline is a feature, not a bug report. The driver app has to hold its state, queue its actions, and sync when it can. Losing a job because a tunnel ate the signal is not acceptable.
- Every request is expensive. Not just in milliseconds — in data the user paid for with real money. Bundle smaller. Cache harder. Don’t refetch what hasn’t changed.
- Loading states have to be honest. A spinner that lies for twenty seconds is worse than a screen that admits “still trying.” Tell the truth about what’s happening.
- The happy path is the rare path. Design the failure first. What does the screen do when the request times out? When the GPS is wrong? When battery saver quietly kills the background sync? That is the actual product.
None of this is exotic engineering. It’s just deciding that the messy reality is the spec — not an afterthought you’ll get to later.
It makes the software better for everyone
Here’s the part people miss. Building for the worst conditions doesn’t only rescue the user on one bar. It makes the app faster, lighter and calmer for the person on fibre too.
Constraints aren’t the enemy of good software. They’re the brief. The teams I’ve seen ship the best products were not the ones with the most resources — they were the ones who couldn’t get away with sloppiness, because their users simply wouldn’t let them.
So I’ll keep designing for the rider in traffic with a dying phone. If it works for them, it works. Everything else is a nice surprise.