When an organisation decides to automate a piece of work, the next question tends to be: do we build it or buy it? It sounds like a fair fork. In practice, it hides a third road that often fits better.
Build: slow, and the risk is in the unknown
Building from scratch gives you exactly what you ask for, and it feels like control. But the expensive part of any new system is not the typing. It is discovery: working out what the process really is, where the exceptions hide, what the data looks like and what “good” means. You pay for that learning in time and in surprises, and you pay for it before you have anything working.
Custom builds also leave you owning something nobody else has used. When it breaks, or the person who understood it leaves, you discover how thin the support is.
Build makes sense when: the capability is what makes you different from competitors, and you are prepared to staff it for years.
Buy: fast, but rarely a perfect fit
Off-the-shelf software is mature, supported and quick to switch on. For common needs such as accounting, email and payroll, it is nearly always the right answer.
The difficulty comes when your process is not the process the product was designed for. Many organisations in Ghana and across Africa have workflows shaped by local regulation, local channels and local habits: insurer claim formats, WhatsApp orders, mobile money reconciliation, data protection rules. A product built elsewhere may handle much of that and force you to work around the rest.
A widely reported 2025 MIT NANDA study, whose methodology critics have challenged, advised buying rather than building. As a rule of thumb that is not unreasonable. As a universal rule, it is too simple, because it assumes the thing you need is on the shelf.
Buy makes sense when: the need is common, and a product fits it with minimal bending.
Co-build: start from a working pattern
The third option is to start from a solution that already runs somewhere, adapt it to your data, rules and systems, and build the missing parts together. That is what we mean by co-build.
It saves the two most expensive things:
- Discovery. The pattern already encodes what we learned from running it: the exceptions, the failure modes, the review steps people actually needed.
- The risk of the unknown. You can see something real before you commit, instead of imagining it from a specification.
And it keeps what buying often removes: a say in every decision, and software that fits the way you actually work.
How we label it
We mark every solution in the catalogue one of two ways:
- Available: it is running in production for a client today.
- Co-build: we have the pattern and much of the engineering, and finish it with you.
We do this because the honest answer to “is this ready?” is usually “part of it.” Saying which part helps you judge timeline and risk. Firms that present a long menu as if everything were ready to go tend to be building each item from scratch behind the scenes, and passing the discovery cost on to you.
A simple way to choose
Ask three questions about the work you want to automate.
| Question | If yes | If no |
|---|---|---|
| Is a common product already a good fit, out of the box? | Buy | Keep going |
| Is this a core capability that differentiates us, which we will invest in for years? | Build | Keep going |
| Does a working pattern exist that is close to what we need? | Co-build | Start with a readiness sprint to find out |
Most organisations land on the third row more often than they expect, because most of their work is specific enough to need fitting, and common enough that somebody has done it before.
What co-build is not
It is not a cheap way to buy a custom system. Adapting a pattern still takes real engineering and real involvement from your team. It is not a licence with a nice name, and it does not mean you are locked in. You own the code, the documentation and the data we produce together, and we hand over cleanly if you want to run it yourselves.
If you are unsure which road you are on
That is the reason for the first stage of our work. A readiness sprint takes two to four weeks, looks at the work and the data, and ends with a recommendation. Sometimes the recommendation is to buy something we do not sell. We would rather tell you that than build the wrong thing.
Sources
- The Great GenAI Divide: debunking the myth of 95% failure, CustomerThink. Describes the MIT NANDA report’s buy-rather-than-build advice and the critique of it.
- Only 1 in 20 AI investments deliver ROI, summary of the MIT NANDA 2025 report