Most software is built with a set of assumptions baked in — assumptions about internet speed, device capability, power reliability, and user behaviour that are drawn from the environments where most software companies operate. Silicon Valley. London. Berlin.
Those assumptions do not hold in Nairobi. And software built on them often fails quietly or loudly when deployed in the Kenyan context.
This is not a criticism of Kenya’s infrastructure — it is a recognition that good software engineering means designing for the environment where your users actually live, not the environment where your developers sit.
Here is how we think about building software that works in Kenya.
Kenya has excellent mobile data coverage and growing fibre penetration in urban centres. But connectivity is not uniform, and it is not always reliable. Traffic congestion in Nairobi means a sales rep on the road may be switching between strong 4G and weak 2G connections throughout the day. Power outages affect routers. Fibre cuts happen.
Software that assumes a constant, high-speed connection will frustrate users and lose data when that assumption fails.
What this means in practice:
Applications used in the field should work offline or on poor connections — capturing data locally and syncing when connectivity is restored. A sales rep taking an order should not need a strong internet connection to do their job.
API calls should have appropriate timeouts and retry logic. When a request fails due to a network hiccup, the application should retry gracefully rather than presenting an error that requires the user to start over.
File uploads — documents, photos, attachments — should handle interruption. Resumable uploads mean that a large file upload that is interrupted by a dropped connection can continue from where it left off rather than starting over.
Background synchronisation should be transparent to the user. The application keeps working; syncing happens in the background when connectivity allows.
In Kenya, mobile is not an afterthought — it is how most people access digital services. A significant proportion of your users will access your system primarily from a smartphone, often on a screen smaller than most developers test on, often with data cost as a genuine consideration.
What this means in practice:
Every interface we build is designed mobile-first — meaning the mobile experience is designed first and desktop is an extension of it, not the other way around.
Page load size matters. A web application that loads 5MB of JavaScript might be acceptable on a fibre connection in a Nairobi office but creates a real barrier for a user on mobile data. We keep asset sizes lean and load only what is necessary for the current view.
Touch interfaces require different design decisions than mouse-based ones. Tap targets need to be large enough to be usable reliably on a touchscreen. Hover states that reveal functionality do not work on mobile.
M-Pesa is the default payment expectation. Any system involving payments needs to treat M-Pesa as the primary payment method — not a secondary option alongside card payments. STK Push should be the default, not a feature.
Power outages affect users, servers, and network infrastructure. A system that loses data or enters a broken state during a power cut is unreliable in the Kenyan context.
What this means in practice:
Browser-based applications should save state automatically. If a user is halfway through a long form and the power goes out, they should not lose their work when they reconnect.
Server infrastructure should be designed with failover in mind — either cloud-hosted with automatic failover, or with appropriate UPS and generator backup for on-premise deployments.
Auto-save and draft functionality for any form that takes significant user effort to complete.
Kenya is multilingual, and while English is the language of business, it is not the first language of every user of every system. Swahili is widely spoken and read. Some users will have lower literacy levels in English than others.
What this means in practice:
Plain language matters. Error messages, instructions, and labels should be written in clear, simple English — not technical jargon. When a payment fails, the message should say “Payment was not completed. Please try again.” not “Transaction timeout exception.”
Where appropriate, Swahili language support can significantly improve usability for certain user groups — field workers, retail staff, users in areas outside major urban centres.
Icon-based interfaces reduce language dependency. Where a visual cue can communicate an action as effectively as text, it should be used.
The most important principle in designing software for Kenya — or anywhere — is to design for the user as they actually are, not as you imagine they might be.
That means testing your software with real users in real conditions. In the field. On mobile data. On lower-end Android devices. In environments with noise and distraction. Not only in a quiet office on a fast laptop with a fibre connection.
Software that passes every test in the development environment and fails in the field is not good software — it is software built to the wrong specification.
At Ndovix, every system we build is tested against Kenyan infrastructure realities before delivery. If you are building a system that needs to work reliably for Kenyan users, talk to us about your requirements.
Found this useful?
Share it with someone who needs to read it.
