Blog · Engineering

Build for the phone in the pocket.

Software for East Africa has to work on a cheap phone, a weak signal and a payment that confirms whenever it feels like it. Six habits that make the difference.

Elvis Chege · 11 October 2026 · 6 minute read

[Draft for Elvis to review and edit before publishing.]

Most software is designed on a fast laptop, on fibre, by people with the latest phone. Most of the people who will use it in Kenya are not in that situation. The gap shows up as apps that time out, payments that get recorded twice, and customers who give up. None of it is hard to avoid if you design for it from the first day.

1. Assume the network will fail mid-request

On a weak signal, the question is not whether a request fails but where. Did it reach the server? Did the server finish? Design every operation that changes something so it can safely be retried: give each one a unique key, and have the server recognise a key it has already handled. Then "retry until it works" becomes a safe strategy instead of a way to charge someone twice.

2. Treat payment callbacks as unreliable messages

M-Pesa confirms a payment by calling your server back. That callback can arrive late, arrive twice, or not arrive at all. A system that only trusts the callback will eventually disagree with reality. Handle callbacks idempotently, record every payment state you see, and run a reconciliation job that checks your records against the statement. The numbers should agree because you checked, not because you hoped.

The callback is a message, not the truth. The statement is the truth.

3. Meet people on the channel they have

A smartphone app is the wrong first answer for many users. USSD works on any phone without data. SMS reaches people who will never open an app. WhatsApp sits in between. When we designed alerts for Uwatu, a livestock-protection system for smallholder farmers, the alert routes through SMS, WhatsApp, USSD or push so that it reaches the farmer on whatever phone they own.

4. Keep USSD menus short and stateless

USSD sessions are short and unforgiving: a slow response or a deep menu ends the session and the user starts again. Keep menus shallow, answer fast, and keep the user's progress on the server so a dropped session can pick up where it stopped.

5. Make offline a feature, not an error

Field agents, clinics and classrooms lose the connection all the time. Let people keep working: save locally, queue the changes, and sync when the signal returns, with clear rules for what happens when two edits collide. Limi, an accessible-learning platform we have been building, prepares whole learning sessions to use offline for exactly this reason.

6. Count your bytes

Data costs money, and slow pages lose people. Send less: smaller images, fewer scripts, nothing loaded until it is needed. This website, with its animated sky, loads in under 90 KB on a phone, and shows its first content in under a second on a slow 4G connection.

The common thread

Every one of these habits comes from the same place: designing for the conditions people actually live in, not the ones in the office. It costs little at the start and a great deal to add later.