Build vs Buy: How African Businesses Should Decide on AI

Every African business that gets serious about AI eventually hits the same fork in the road: do we build our own, or do we buy something off the shelf? It sounds like a technical question. It is not. It is a question about money you do not have, skills you cannot easily hire, and control you may or may not need. Get it wrong in the "build" direction and you burn a year and a fortune reinventing a chatbot. Get it wrong in the "buy" direction and you hand your core business logic to a vendor who can raise prices or disappear.

My thesis: for the overwhelming majority of African SMEs, the honest answer is buy first, integrate carefully, and build only the thin slice that is genuinely your competitive edge. Building AI from scratch is a rich-company sport. But "buy" is not one decision either - there is a spectrum, and knowing where you sit on it is the whole game.

The spectrum nobody explains

"Build vs buy" is really four options, not two:

Option	What it means	Best for
Buy a finished product	Subscribe to a tool that already does the job (a WhatsApp chatbot platform, an AI writing tool)	Common problems, small teams, fast results
Buy and configure	A platform you customise heavily with your data and rules, no code	Businesses with a specific workflow but no engineers
Build on top of an API	Use an existing model (OpenAI, Anthropic, a local model) but write your own logic around it	Businesses with one developer and a unique process
Build the model itself	Train or heavily fine-tune your own AI	Almost nobody outside big banks, telcos and funded startups

Notice that the fourth option, the one people imagine when they say "build AI," is the one you almost never want. Training models needs data, GPUs and specialised talent that command salaries three to four times higher than the average employee, according to Gartner. In a Nairobi or Lagos market that talent is scarce and expensive, and it leaves. Unless training a model is your product, skip it.

Most real decisions live between the second and third rows - "buy and configure" versus "build on top of an API." That is the genuine fork for an ambitious SME, and it turns almost entirely on whether you have a developer you trust and a workflow that no existing product quite fits. Everything below is designed to place you on that spectrum honestly, rather than flattering you into a build you cannot sustain or scaring you out of an edge you should own.

A decision framework you can actually use

Ask these five questions in order. The first "yes" that points to build is the only thing that justifies building.

1. Is this task your competitive advantage, or just plumbing?

Customer support, invoicing, content drafting and scheduling are plumbing. Every business has them, and someone already sells a good tool. You gain nothing by building them yourself. Build only where the AI touches the thing that makes customers choose you - a unique credit-scoring model for your lending book, a matching engine for your marketplace. If it is plumbing, buy it.

2. Does a good local-fit product already exist?

The African tooling market has matured. There are Kenyan and Nigerian vendors offering WhatsApp AI chatbots, M-Pesa and Paystack integrations, and support for local realities out of the box. Buying local often means the integration you actually need already works. Do a real market scan before assuming you must build.

3. Do you have, and can you keep, the technical talent?

Building means hiring or retaining developers who understand AI. Be brutally honest: one talented engineer who leaves after eight months does not leave you with a system, they leave you with an abandoned one you cannot maintain. If you cannot fund and retain at least two capable people, do not build something the business will depend on.

4. How much control and data ownership do you truly need?

This is where buy has a real cost. A vendor holds your data, sets your price, and owns the roadmap. If you operate under Kenya's Data Protection Act or Nigeria's NDPA 2023, you remain the data controller and stay liable even when a vendor processes the data. Read where data lives, who can see it, and what happens if you leave. Sometimes those answers push a sensitive workflow toward build. Usually they just push you toward a better contract.

There is also a subtler control question: lock-in. A tool that holds your customer history, your prompts and your tuned configuration is a tool that is painful to leave, and vendors know it. Before you commit, ask the unglamorous question - if this company doubles its price or shuts down next year, how do I get my data out and how long would switching take? If the honest answer is "we would be stranded," that is a reason to either negotiate export rights up front or keep the crown-jewel logic in your own hands, even while you buy everything around it.

5. What is the total cost over three years, not one month?

A subscription looks cheap next to a developer salary. But buying at scale can get expensive as you grow, and building carries maintenance forever. Model both over 36 months, including the hidden costs of integration and change management. The monthly sticker price is the smallest number in the equation.

Build when the AI is your moat. Buy when the AI is your plumbing. Most of what a business does is plumbing.

When buy clearly wins

• The problem is common (support, marketing copy, bookkeeping, scheduling).
• You have fewer than a handful of technical staff.
• You need results this quarter, not next year.
• Your budget cannot absorb a failed six-month build - and remember, MIT found 95 percent of custom enterprise AI builds delivered no measurable return in 2025.

When build starts to make sense

• The AI capability is the product, or the direct reason customers pick you.
• No existing tool fits your workflow, and you have verified that by trying.
• You have funded, retainable engineering talent.
• Data sensitivity or regulation genuinely forbids handing the workflow to a third party.

The middle path most winners actually take

Here is the pattern I see working across the continent. Businesses buy the boring 80 percent - the chatbot platform, the transcription tool, the analytics dashboard - and build a thin custom layer only on the 20 percent that is theirs, usually on top of an existing model's API rather than training anything. A logistics firm buys its WhatsApp automation but writes its own routing logic. A lender buys its document processing but owns its risk model. This gives you speed where speed is free and control where control matters.

The instinct to build everything is usually ego, and the instinct to buy everything is usually laziness about your own edge. Resist both. Map your tasks into plumbing and moat, buy the plumbing without shame, and spend your scarce engineering effort only on the moat. That is not a compromise. For a business working with constrained budgets and thin teams, it is the strategy. And whichever way you lean, do not let a vendor stampede you into a decision before you have honestly assessed whether your business is ready.