There's a design assumption baked into most modern software that I've had to
unlearn: that the network is there. That it's fast, cheap, and always on. Build
between Benin City and Porto Alegre for long enough and you stop believing it.

When you build for places where data costs real money and connectivity comes and
goes, you start designing for the last bar of signal — the moment when the
connection is weakest, not strongest. That single shift changes almost every
decision.

The message has to land, not just send

In a well-connected world, "we sent it" and "they got it" are nearly the same
sentence. In a low-bandwidth world they are completely different claims. A push
notification needs an installed app, an open data connection, and a user who
opens the app. Each of those is a place the message can quietly die.

That's why I lean on channels that degrade gracefully:

• SMS reaches any phone, no app, no data. It's the floor that never drops.
• Plain text and small payloads load on a weak connection where a heavy page never finishes.
• Delivery receipts, where you can get them, turn "sent" into "arrived" — the only number that actually matters.

Small is a feature, not a limitation

A 2-megabyte page isn't "rich." On a metered, intermittent connection it's a
toll booth. Every image, every script, every font is something the user pays for
in money and patience. Designing small — fewer assets, lighter pages, text that
survives compression — isn't austerity. It's respect. It says: I know what this
costs you, and I've kept it cheap.

The same goes for resilience. Can the task be finished if the connection drops
halfway? Can it be retried without doing damage? Can a non-technical person tell
whether it worked? In a low-bandwidth context these aren't edge cases. They're
the main case.

Why this matters beyond convenience

It's easy to frame low-bandwidth design as a niche constraint. It isn't. It's how
a large share of the world actually comes online — on phones, on mobile data, in
bursts. When we design only for the fast, cheap, always-on network, we quietly
build for the people who already have the most and leave out the people a school,
a clinic, or a public service most needs to reach.

Designing for the last bar of signal is, in the end, just designing for everyone
honestly — including the people whose connection is the worst on the day it
matters most.

Joan Urevbu (Joan Osunde) is a technologist and writer focused on education. She
builds the unglamorous, high-stakes software that decides whether a parent gets
the message and a school day starts on time — timetabling, gate logistics, and
messaging systems built for low-bandwidth, high-trust environments. Working
between Benin City, Nigeria and Porto Alegre, Brazil, she writes about building
technology for African education. More at joanurevbu.com.