The Question Every Growing Business Hits
At some point, every business in East Africa that is scaling — a fintech, a logistics company, a retailer with branches — hits the same fork in the road. The off-the-shelf tool that used to work now forces your operations to bend around it, and someone on the team says the sentence that starts a project: "Let's just build our own."
It is an expensive sentence to get wrong. A custom build costs hundreds of thousands of shillings and takes months. An off-the-shelf package can look free until you realise you are paying in process inefficiency instead of money. The decision is not about which option is objectively better. It is about which one your business model can actually live inside.
This guide gives you the decision framework we use at Mwenaro Labs when clients ask us to build custom software, plus the scoping process we run before writing a single line of code. For the wider strategy, start with our guide to the full stack developers who build these systems.
What "Off-the-Shelf" Actually Buys You
Off-the-shelf software means you rent a product designed for thousands of companies like yours. Examples: an accounting package, a CRM, an e-commerce platform, a booking system. What you actually buy is four things:
What you do not buy is fit. The product was designed for the average company, and your company is not average — your approval workflow, your reporting, your integration with mobile money APIs all differ. The real question is whether those differences cost you more than the subscription saves you.
When Off-the-Shelf Is the Right Call
Off-the-shelf wins when the process is genuinely commodity. If every business in your sector does the same thing the same way, a generalised tool is usually good enough. Signs you should buy, not build:
The classic mistake here is assuming custom is inherently better. It is not — it is just more tailored. For many African SMBs, a good SaaS package deployed correctly beats a mediocre bespoke build that was over budget and late.
When You Need Custom Software
Custom software is the answer when the software is the business, not a support function. You should build when any of these are true:
There is a middle path too: build the core that differentiates you, buy the surrounding commodity software, and integrate them. In our experience this "hybrid" is the right answer for most mid-sized African companies, and it is exactly how we scope builds at Mwenaro Labs.
The Real Cost of Custom Software
Custom software is expensive, and the biggest cost is rarely the code. A realistic budget has five parts:
Most first-time buyers only budget for #2, then get blindsided by #1, #4 and #5. A realistic custom build starts at several thousand dollars and runs to tens of thousands for a substantial platform. That is why the decision framework above matters more than the estimate — you should not start scoping until you have a reason to build.
How We Scope a Build Before Writing Code
Before Mwenaro Labs writes a line of code, we run a two-week discovery phase that produces three things: a process map, a data model, and a priority feature list. The goal is to de-risk the estimate and to catch the "build vs buy" decision again with better information — because discovery frequently reveals that 70% of what the client wanted can be bought.
The scoping questions that matter most:
The output of discovery is a fixed-scope proposal with a price, a timeline, and an explicit list of what is out of scope. If a vendor will not give you that, treat it as a warning sign. For a sense of how real client work is structured, the engineering chronicle documents projects exactly like this.
Making the Decision
Work through this in order:
If you would rather talk this through with engineers who do it daily, Mwenaro Labs runs discovery engagements for businesses across East Africa. The Enterprise cluster has more guides like this one, including the fintech stack that powers most local custom builds.