Kenya’s Custom Software Market Has a Maintenance Problem That Nobody Discusses at the Proposal Stage
Custom software projects in Kenya are typically approved based on development cost, but their true financial impact only becomes visible years later.
As original developers leave and undocumented code accumulates, maintenance shifts from routine support to expensive reverse engineering. Feature updates slow, risks increase, and regulatory changes expose architectural limitations that were never designed for.
Every custom software proposal in Kenya presents a development cost. Almost none of them present a total cost of ownership. The gap between those two numbers is where the catastrophe lives.
A conservative five-year TCO model for a typical Kenyan custom software project built in 2020 or 2021 on a PHP/Laravel stack at a development cost of KSh 4 million looks like this. In year one, with the original development team maintaining the system and the codebase still fresh in their knowledge, maintenance costs are manageable — approximately KSh 300,000 for bug fixes, minor enhancements, and hosting management. The system is performing as expected. The client believes the budget conversation is over.
In year two, the first developer change happens. This is not unusual — Kenya’s technology talent market is mobile, and developers who built a system at one rate in 2021 are frequently earning significantly more by 2023 and moving to where that rate is offered. The replacement developer requires knowledge transfer. The parts of the codebase that were documented transfer cleanly. The parts that were not require reverse engineering. Maintenance cost for year two: KSh 600,000 in maintenance plus KSh 400,000 in knowledge transfer time. Total: KSh 1 million.
Year three is where the model breaks. A second developer change occurs, and the documentation gaps that were manageable during the first transition have now compounded. The new developer is working from incomplete records of a system they did not build, maintained by someone who also did not build it. Feature requests that would have taken two weeks in year one now take six because the developer must first understand what exists before changing it. Maintenance cost: KSh 1.2 million. Onboarding cost: KSh 600,000. Total: KSh 1.8 million for the year.
By year four, the accumulated technical debt — the shortcuts, undocumented logic, and architectural decisions made under original development budget pressure — begins to demand payment. Feature requests require architecture changes that were not anticipated. A new regulatory requirement, a new API integration, a new reporting standard: each one requires touching the system at a level that the current team is not confident in. Year four cost: KSh 1.8 million. Year five, when a significant regulatory or integration requirement triggers a partial rebuild: KSh 2.5 million.
Total five-year cost on a KSh 4 million original development budget: KSh 10.9 million. The TCO is 2.7 times the development cost. That figure was never in the business case. The organisation made a procurement decision based on year-zero cost and is now funding years three through five from a budget that did not anticipate them.
The most uncomfortable element of this model is that it is conservative. It assumes the system continues to function. It does not price the scenario where the system fails during a critical operational period and the organisation has no recovery documentation.
Stack, documentation, and test coverage determine future costs
The maintenance catastrophe is not randomly distributed across Kenya’s custom software portfolio. It clusters around systems where three specific decisions were made at development time in the direction of lowest upfront cost rather than lowest total cost. Understanding those decisions gives any organisation evaluating a new custom software proposal a precise checklist for avoiding the year-three outcome.
The first decision is stack selection. A technology stack with a deep local talent pool produces structurally lower maintenance costs than one with a shallow pool, because the labour market for developers who can work on the system is larger and more competitive. PHP/Laravel has the largest developer community in Kenya. A system built on a framework with a thin local talent base is not merely harder to maintain — it is harder to maintain at a price that reflects the work involved, because the supply of people who can do the work is constrained. Stack selection is presented at the proposal stage as a technical decision. It is equally a long-term labour market decision, and it should be evaluated as one.
The second decision is documentation standards. A system delivered with complete technical documentation — architecture diagrams, database schema, API specifications, deployment guides, and development environment setup instructions — can be handed to any competent developer who works in that stack and maintained from day one. A system delivered without that documentation can only be maintained by someone who already understands it, which means the original developer, or someone who has paid the substantial cost of reverse engineering it. Documentation adds 10 to 15% to development cost. The absence of documentation adds, conservatively, 40 to 60% to years-three-to-five maintenance cost. No procurement decision that saves money on documentation and externalises that cost to future maintenance is a rational procurement decision.
The third decision is test coverage. A codebase with automated test coverage above 60% of core business logic can be modified with confidence — changes to one part of the system surface problems in other parts before they reach production. Without test coverage, every change to a mature codebase is an uncontrolled experiment. The developer who wrote the code knew what it depended on. The developer maintaining it three years later does not, and will only discover the dependencies when something breaks in production at 2am on a Tuesday. Organisations that are currently experiencing the frustration of slow feature development velocity in their legacy systems are frequently experiencing the downstream consequence of test coverage decisions made at year zero.
These three decisions together add 10 to 25% to development cost and reduce years-three-to-five maintenance cost by 60 to 80%. The ROI is not ambiguous. The reason these decisions are made in the direction of short-term saving rather than long-term optimisation is that the procurement process rewards low year-zero cost and the person making the decision in year zero is frequently not the person paying the maintenance cost in year three.
Five essential contract clauses for maintainable custom software in Kenya
The documentation problem can be solved at procurement, but only if the procurement contract specifies documentation as a deliverable rather than an expectation. Most Kenyan custom software contracts specify functional requirements. They describe what the system should do. They do not specify what the development team must hand over alongside the working system to ensure that the system remains maintainable after the original developers depart.
Every custom software contract in Kenya should include five specific documentation deliverables as acceptance criteria — meaning the project is not complete, and the final payment is not due, until these items are delivered to a defined standard.
The first is a technical architecture document: a written description of the system design, including database schema, API specifications, third-party service integrations, and the architectural decisions that determined how the system was built. This is the document that allows any competent developer to understand the system’s structure without reading every line of code.
The second is a deployment guide: step-by-step instructions sufficient for a competent system administrator to deploy the application from scratch onto a new server without assistance from the development team. An organisation that cannot deploy its own software without the original developer is not the owner of that software — it is the hostage of the developer relationship.
The third is a development environment setup guide: instructions for a new developer to set up the development environment and run the system locally in under four hours. If this takes longer than four hours, the documentation is not complete.
The fourth is an automated test suite covering at minimum the core business logic — the calculations, validations, and process flows that the organisation depends on. The test suite is not for the original development team. It is for every developer who will ever touch the system after them.
The fifth is an operations runbook: documented procedures for the failure scenarios most likely to occur in production — database connection failures, third-party API outages, backup restoration, and common error conditions. The runbook is the document that determines whether a 2am production failure takes two hours to resolve or eight.
If a vendor declines to include these deliverables as contract obligations, that is not a negotiating position to be accommodated. It is a signal about how the vendor intends to manage the post-delivery relationship and what kind of dependency they are planning to maintain.
Rebuild or Rescue: Assessing What You Actually Have
For organisations already in the year-three situation — increasing costs, decreasing velocity, growing developer dependency — the first management question is whether the system can be rescued through a structured modernisation programme or whether it requires a complete rebuild. Getting this question wrong is expensive in either direction: organisations that rescue systems that should be rebuilt spend three years and KSh 4 million deferring an inevitable outcome; organisations that rebuild systems that could be rescued spend KSh 6 million solving a problem that KSh 2 million would have addressed.
The assessment requires evaluating the system against four independent dimensions. The technical dimension asks whether the codebase is maintainable by a competent developer in a reasonable timeframe — this is a code quality assessment that examines documentation coverage, test coverage, architectural coherence, and dependency currency. The functional dimension asks whether the system covers current business requirements or whether requirements have grown beyond what the original design can accommodate without structural changes. The regulatory dimension asks whether the system is compliant with current requirements — KDPA data handling standards, the Digital Health Act’s facility reporting requirements for healthcare systems, and current Daraja v2 integration standards for any system handling M-Pesa transactions, noting that systems built against the original Daraja API are approaching end-of-support conditions that will force integration work regardless of other considerations. The integration dimension asks whether the system connects correctly with the platforms the organisation now depends on, including iTax for organisations with payroll integration requirements, and the CBK’s payment system standards for financial services applications.
Score each dimension from one to five. Systems scoring below twelve require rebuild — the accumulated technical, functional, regulatory, and integration debt has exceeded the cost of starting with a clean architecture. Systems scoring between twelve and sixteen can typically be rescued through a structured modernisation programme that addresses the highest-risk gaps first. Systems scoring above sixteen can be maintained with standard support and incremental improvement.
The pushback against this assessment — and it is a consistent one — is that the organisation should simply migrate to an off-the-shelf system rather than invest further in custom software. This is sometimes correct. But it rests on an assumption that the data and process documentation required for migration exists. In most legacy custom software situations, the documentation that would enable a clean migration to an off-the-shelf ERP or CRM is precisely the documentation that was never created. The migration from a poorly documented custom system to an off-the-shelf alternative requires first recovering that documentation through a system audit — at a cost that frequently equals or exceeds rebuilding the custom system correctly. The documentation problem does not disappear when the organisation decides to migrate. It becomes a migration problem at migration cost.
Preventing the Five-Year Catastrophe
Jansen Tech builds and maintains custom software for Kenyan organisations with explicit TCO modelling built into the procurement conversation — including stack selection rationale, documentation standards as contract deliverables, and a post-delivery maintenance framework agreed before the first line of code is written. For organisations already in the year-three situation, we conduct legacy system assessments against the four-dimension framework above and deliver a structured recommendation on rebuild versus rescue with a cost model that makes the total ownership picture visible before the decision is made. This work is not unusual in technically mature markets. In Kenya’s custom software market, where the proposal conversation has historically been optimised around year-zero cost, it remains rarer than it should be.
The organisations paying the highest technology maintenance costs in Kenya in 2025 are not those that made the wrong technology choices. They are those that made the cheapest technology choices. In custom software, the lowest development proposal and the lowest total cost of ownership are almost never the same proposal, and the gap between them compounds with every developer change, every undocumented dependency, and every regulatory requirement that requires touching an architecture nobody fully understands.
The assessment framework above gives any organisation with a legacy custom system a starting point for understanding where it sits on the spectrum from manageable to catastrophic — and what it would cost to address the gaps before they reach the point of no recovery. The healthcare company with the undocumented patient management system and the KSh 1.8 million audit bill is not an outlier. It is where the five-year TCO model was always going. The question for every organisation that commissioned custom software in 2020 or 2021 is a simple one: where are you on that trajectory, and how close is year three?
