Web Development in Kenya
Web development and product guidance for Kenyan teams: build-versus-buy, custom applications, and integrating M-Pesa properly.
Written and reviewed by Haryes Kebeya, Founder & Lead Developer · 8 guides planned
What these guides cover
This cluster is for Kenyan businesses considering custom software: a client portal, a booking system, an internal tool, or a platform that moves money over M-Pesa.
Before you write code
Build versus buy, and how to scope a first version that ships and earns before it grows.
Budget and timeline
What a realistic budget and timeline actually look like for custom software.
Daraja for production money
Idempotency, callback verification, reconciliation and the failure cases, done safely.
Avoiding a liability
How a custom build turns into an unmaintainable liability, and how to avoid it.
When a business actually needs a system
Most Kenyan businesses that ask for custom software need less of it than they think, and need it sooner than they expect. The signal is not size; it is repetition. A process that several people follow every day, recorded in a spreadsheet, coordinated over WhatsApp, and reconstructed from memory when somebody is away, is a process a system pays for.
The opposite signal is a workflow that changes every month or exists to serve one person. Those are better left in a spreadsheet, where changing them costs nothing.
Between the two sits the most common honest answer: buy the off-the-shelf product for the standard part, and build only the part that is genuinely specific to how your business operates.
Scoping a first version that survives contact
The failure mode for custom software here is a long build against a specification written before anyone used anything. Eighteen months later the business has changed and the system encodes a process nobody follows.
The alternative is narrow and quick: one workflow, the one that costs the most time, taken end to end into production with real users on it. The second release is then shaped by how the first is actually used, which is far better information than any requirements workshop produces.
That also changes how it is paid for. Discovery is bought on its own and produces a written specification you own; the build is staged against milestones rather than a single figure at the start.
The parts nobody budgets for
A system is something you now operate, not something you bought. That means staging and production environments, automated backups that somebody has restored, monitoring that alerts before a user reports a failure, and a support arrangement with agreed response times.
It also means duties. Anything holding customer or member records falls under the Kenya Data Protection Act: collect what the process needs, restrict access by role, keep an audit trail, set retention periods, and be able to export or delete a record on request.
Most importantly it means adoption. The measure of an internal system is not whether it works but whether the team stopped using the spreadsheet, which is a training and change question as much as a technical one.
Connecting to the systems you already run
Almost nothing is built in isolation. There is usually accounting software, a payment provider, a website, a stock system, or years of spreadsheets that have to come across. How that data is modelled at the start decides what the system can do in its third year.
Integrations divide into three honest categories. Some systems offer a proper interface and can be connected directly. Some offer a scheduled export, which is less elegant and perfectly workable. Some offer nothing, and the real answer is a structured import somebody runs weekly rather than a promise that cannot be kept.
Migrating existing records is a project of its own: cleaning, removing duplicates, deciding what not to bring, and running the import twice, once as a rehearsal and once for real. Budgeting for it separately is the difference between a launch and a month of firefighting.
Working offline, or nearly
Many Kenyan systems are used away from a desk: a field officer recording visits upcountry, a driver confirming delivery, an agent registering a member at a kiosk. If the software assumes a stable connection, those users fall back to paper and re-enter it later, which reintroduces the errors the system existed to remove.
Designing for it means forms that survive a dropped connection, submissions that retry rather than vanish, and clear feedback about what has and has not been saved.
Signs a business has outgrown its spreadsheets
Several people edit the same file and the versions diverge. Somebody has to be asked before a figure can be trusted. A report takes an afternoon to assemble because the data lives in four places. The answer to “what happened to this order” is a WhatsApp thread.
Those are the honest triggers, and they are all about coordination rather than volume. A business with two hundred records and five people touching them needs a system before one with five thousand records and a single user does.
The counter-signal matters too. If only one person uses the process, or it changes every month, leave it in the spreadsheet where changing it is free. Software is worth building when the process has settled enough to be worth encoding.
When it is time, start with the workflow that costs the most hours rather than the one that is easiest to describe. Put that single workflow into production with real users on it, watch how they actually use it for a month, and let the second release be shaped by what you learn rather than by the feature list written before anyone had used anything.
Articles in this cluster
How these guides are written
Every page in this cluster is held to the same standard, because a page that ranks but tells you nothing new wastes your time and ours.
A named author and reviewer
Written by the people who do the work, not a separate content team. No anonymous posts.
Answer first
The core question is answered in the opening lines, before any background.
Information gain
Each guide has to add first-hand process detail or specific Kenyan context a generic article cannot copy.
Kept current
Guides are revisited as M-Pesa, eTIMS, Google and the AI answer engines change.
Where this cluster leads
Every guide links down to the service that does the work, and across to the neighbouring topics.
Need ui/ux design in Kenya?
This cluster bridges to UI/UX Design in Kenya. UI/UX design covers how a digital product works (user experience) and how it looks and responds (user interface). Haryes Web Developers provides UI/UX design in Kenya as a standalone deliverable (research, wireframes, interface design, and documented design systems handed over as Figma files) for teams that have their own developers.
Rather just ask?
Send your brief and get a fixed scope and price back within a working day.
