Build vs Buy: The Second Developer Problem
Custom software quotes in Nairobi look competitive against three years of subscription and almost never account for the second developer. The four questions that decide it, the failure mode nobody prices, and the two cases where building genuinely wins.
A Nairobi development shop will build you an inventory and procurement system for somewhere between KES 800,000 and KES 3 million. Set against KES 76,400 a year of subscription, the arithmetic looks obvious in about year eleven — which is roughly where the comparison stops being useful, because no custom system built in 2026 will still be running unmodified in 2037.
The real comparison is not build cost against subscription. It is build cost plus maintenance plus the developer risk, against subscription plus the compromises of somebody else's product. Both sides have a genuine case and the decision is usually made on the wrong axis.
The four questions
Answer these before comparing any numbers
Is what you do genuinely unusual, or just familiar?
If the answer is
"Nobody does it the way we do."
Then
Usually that means nobody has written down the way you do it. Genuine structural uniqueness is rare — a leasing model nobody supports, a pricing rule no product accommodates, a regulator with a format nobody meets. Habit dressed as uniqueness is the most expensive reason to build.
Who maintains it in year three?
If the answer is
"The developer who built it."
Then
Then price the risk that they are unavailable. A custom system whose author has moved on is a system nobody will touch, and the second developer's first quote is always to rewrite it. This is the single largest hidden cost in building.
Who decides what it should do?
If the answer is
"We'll work that out with them."
Then
A custom build requires you to specify the thing. A product embodies a thousand decisions somebody already made — often ones you would not have thought to make, like whether a blind count discloses expected quantities. Specifying those yourself is real work and it is where custom projects overrun.
What happens when the tax authority changes something?
If the answer is
A pause.
Then
eTIMS changed, and will change again. A product distributes that cost across every customer. A custom build makes it your project, at your expense, on the authority's timetable rather than yours.
The honest five-year comparison
Custom build versus subscription, 40-staff distributor
The maintenance line is the one people omit, and 15% of build cost a year is a conventional and conservative figure. Note also what is identical on both sides: your own implementation effort. Building does not remove data cleaning, the counting day or the training hours — it adds specification work on top of them.
The failure mode nobody prices
The custom system works, for two years, and then the developer becomes unavailable — a better job, a move, a disagreement, a business that closes. Nothing is documented beyond the code. The next developer looks at it and quotes to rewrite, because reading somebody else's undocumented system is harder than writing your own and every developer knows it.
This is not a small risk in this market; it is the median outcome of a small custom build. And it is why the two mitigations below matter more than anything in the contract price.
If you build, insist on these
- Source code in your repository, from day one, not delivered at the end. A build that lives on the developer's machine until the final invoice is a build you do not own yet.
- A second person who has read it. Anyone. A contractor for two days, a review by another shop. The point is that at least one other human has seen inside.
- Written documentation of the decisions, not the code. Why the threshold works that way, why receiving is separate from adjusting. Code explains what; nothing recovers why.
- Your own hosting account. Not the developer's. This is the difference between a supplier relationship and a hostage situation.
- A working export of everything, tested, before final payment. The same question you would ask any vendor about leaving.
Where building genuinely wins
Build
The thing you sell is the process
If your competitive advantage is a way of operating that no product supports — a specific leasing structure, a pricing model, a matching algorithm — then that part is not overhead, it is the business. Build that piece. Buy everything around it.
Build
A narrow tool alongside a bought system
The highest-return custom work in this market is small: one screen, one calculation, one integration that pushes to an API. Two to six weeks, clearly bounded, and it sits beside a product that handles the ordinary ninety per cent. This is almost always the right answer when "we need custom" comes up.
Buy
You need inventory, procurement, sales and accounting
These are solved problems with a thousand edge cases each. Building them means rediscovering the edge cases at your own expense, in production, one angry customer at a time.
Buy
Anything touching a tax authority
The cost is not the integration, it is the changes. A product amortises those across its customers; a build makes each one your project on the authority's schedule.
The middle path most people miss
Buy the platform, then commission the one thing it does not do — against its API, as a separate small system that reads and writes. You get the ordinary ninety per cent maintained by somebody else and the ten per cent that is genuinely yours built exactly as you need. Ask about API stability before scoping it; ours is real and carries no version guarantee, which is a conversation worth having before anyone writes code.
Our take
Buying wins by two to four times over five years for ordinary operations, and the gap is mostly maintenance and the second-developer problem rather than the build price. Build only where the process is the product, or as a narrow tool beside a bought system. And if you do build, get the source in your repository on day one and make sure a second person has read it — that single condition removes most of the risk that makes building expensive.
Buy the ordinary, build the unusual
Talk to us about which ten per cent of your requirement is genuinely yours. We would rather point you at an API and a small custom tool than sell you a platform you will fight for two years.
See plans & pricingFrequently asked questions
Is it cheaper to build custom software or subscribe?
Subscribing, by roughly two to four times over five years for ordinary operations. A Nairobi build for inventory and procurement runs KES 800,000–2 million, and the line people omit is maintenance at a conventional 15% of build cost a year, plus hosting and at least one regulatory change. Your own implementation effort is identical either way — building adds specification work on top of it.
What is the biggest risk in commissioning a custom build?
That the developer becomes unavailable in year two or three and nothing is documented beyond the code. The next developer quotes to rewrite rather than read, because reading somebody else's undocumented system is harder than writing your own. In this market that is close to the median outcome for a small custom build, not an edge case.
What should we insist on if we do build?
Source code in your own repository from day one rather than delivered at the end; at least one other person who has read it; written documentation of the decisions rather than the code; your own hosting account rather than the developer's; and a tested full export before final payment. The first and second between them remove most of the risk that makes building expensive.
When does building genuinely make sense?
Two cases. When the process is the product — a leasing structure, a pricing model or a matching rule that is your actual competitive advantage. And as a narrow tool alongside a bought system: one screen, one calculation, one integration, two to six weeks, clearly bounded. That second case is almost always the right answer when "we need something custom" comes up.
Can we buy a platform and build the missing part?
Yes, and it is the option most people miss. Buy the ordinary ninety per cent and commission the ten per cent that is genuinely yours against the API. Ask about API stability before scoping it — ours is real, permission-bound and audited, and carries no version guarantee, which is a conversation worth having before anyone writes code rather than after a release.
