How Much Does Custom Software Cost in Kenya?
What drives custom software cost in Kenya — scope, roles, integrations, compliance — why fixed-price quotes for undesigned systems fail, how phased pricing protects you, and the true cost of the cheapest developer.
Ask five firms what your system will cost and you will receive five numbers spanning an order of magnitude, because you asked a question that cannot yet be answered. Nobody knows what the system costs, including you, because nobody has yet decided what it is.
That is not evasion. It is the central fact of buying software, and the firms that pretend otherwise are the ones you should be most careful with.
What actually drives the number
Software cost is essentially engineer-time, and these are the variables that determine how much of it your system honestly needs.
- Number of distinct user roles — each role means its own permissions, screens and testing surface. Three roles is not half the work of six.
- Integrations — every external system (M-Pesa, eTIMS, a bank, a legacy database) adds development, error handling and an entire class of failure to be tested.
- Mobile — a mobile app is a second product with its own build, release and testing cycle, not a view of the web app.
- Compliance and security burden — a lending platform holding financial data carries obligations a booking tool does not, and that work is real.
- Data migration — moving from an existing system is frequently a bigger job than the new features.
- Design ambition — a functional interface is far cheaper than a distinctive one, and both are legitimate choices.
Why a fixed price for an undesigned system is a fiction
When a firm quotes a fixed total for a system that has not been designed, one of three things is happening. They have padded the estimate heavily to absorb the unknowns, and you are paying for their uncertainty. Or they have underbid to win the work and will recover it through change requests, which is the most common. Or they genuinely do not know, and the project will fail.
There is no fourth possibility. The unknowns are real, and someone bears them: either you pay for them upfront in padding, or you fight about them later in change orders.
The way out is not to find a firm brave enough to guess. It is to pay for design before you pay for construction.
Phased pricing, and why it protects you more than us
We quote a discovery and design phase first — a defined, modest, fixed-price piece of work that produces the specification, the architecture, the interface design and a costed build plan. At the end of it, the system is designed and the build can be quoted properly, because now somebody knows what it is.
Then you decide. You may build with us. You may take the design elsewhere and have it built, which is your right, since you own it. You may look at the number and conclude the project is not worth it — and discovering that after a small, contained spend rather than halfway through a large one is a success, not a failure.
This structure is deliberately weighted against us. It gives you a natural exit before the expensive commitment. We prefer that to a client six months into a build they never wanted.
The true cost of the cheapest developer
It is not the fee. It is the rebuild.
The most expensive projects we take on are second attempts — a system built cheaply by a freelancer or a low-cost shop, launched, and then found to be unmaintainable. No tests, so no change is safe. No documentation, and the developer is unreachable. Credentials committed to the repository. An architecture that cannot support the second office, the second product, the tenth thousand user.
The client then pays twice: once for the original, once for the rebuild, plus the opportunity cost of the year in between. We audit these systems regularly, and we have told clients their foundation was sound and should be extended — but the majority of the time the honest recommendation is to start again, and it is not what anyone wants to hear.
This is not an argument for the most expensive quote. It is an argument for asking what tests exist, what happens when the developer leaves, and to see something they built three years ago that is still running.
How to buy software without gambling
Pay for discovery separately, and own its output. Insist on working software every few weeks rather than at the end, so you can see progress rather than be assured of it. Confirm in the contract that you own the source code and the intellectual property. Ask what the automated test coverage will be and treat any confusion about the question as an answer.
Then ask the question that matters most and that almost nobody asks: what happens if we want to leave? A firm that has a clean, unembarrassed answer — here are your repositories, your infrastructure, your documentation — is a firm that intends to keep you by being good.
Key takeaways
- Cost is driven by roles, integrations, mobile, compliance and migration — not by page count.
- A fixed price for an undesigned system means padding, underbidding, or a project that will fail.
- Pay for discovery and design first, as a small contained phase, then quote the build against a real specification.
- The cheapest developer is usually the most expensive, because you pay again for the rebuild.
- Insist on source-code ownership, working software every sprint, and a clean answer to 'what if we leave?'
Frequently asked questions
Why won't you just tell me a price?
Because any number we gave you now would be wrong, and you would anchor to it. We do not know how many user roles your system has, whether it integrates with your bank, whether it needs a mobile app, or whether it holds personal data that brings regulatory obligations — and neither, in our experience, do you yet, in the detail required. What we will do is scope on a call at no cost, tell you the range of shape the project takes, and quote a fixed price for a discovery phase that produces a real specification and a real build cost. Firms that quote before that conversation are guessing, and their guess is structured to win the work rather than to be accurate.
Is it cheaper to hire an offshore development team?
The day rate is lower and the total frequently is not, though this cuts both ways and we are ourselves an offshore team to a European client. The costs that erode the saving are timezone latency on decisions, the communication overhead of a team that does not understand your market, and — most significantly for Kenyan systems — the absence of local context. A team that has never integrated M-Pesa will spend weeks learning what the Daraja callback semantics actually are, and will still get idempotency wrong on the first attempt. Judge on demonstrated outcomes and on whether they understand your domain, not on the rate card.
What happens if the project runs over budget?
With phased pricing, considerably less than you fear, because each phase is separately scoped and separately quoted, so an overrun is bounded by the phase rather than by the project. If work within a phase runs long because we estimated it badly, that is our error and our cost. If it runs long because the scope changed — you asked for something that was not in the specification, which is entirely normal and often correct — we tell you the cost before doing the work, never after. The pathology to avoid is the fixed-price contract for a vague scope, where every clarification becomes a billable change request and the relationship becomes adversarial by month three.
How do we know a quote is realistic?
Interrogate the assumptions rather than the total. Ask how many engineer-weeks it represents and who specifically will do the work. Ask what is explicitly excluded — the exclusions are where overruns live. Ask what the testing approach is, and whether the estimate includes writing tests or merely writing features. A quote conspicuously below the others is not a bargain; it is a different scope, a more junior team, or an underbid to be recovered later. Ask that firm what they have removed to reach their number. If they cannot say, they have removed the parts you will miss.