We have spent two articles arguing that the technical barrier to building a company in Africa has collapsed. A founder with no engineering background can now ship a working product in a weekend, and we have said plainly that this should change what a technical co-founder is worth. So the title of this piece looks like a contradiction.
It is not. The build barrier fell. The operate barrier did not move at all — and in Africa it was always the higher of the two.
What follows is the case for technical partnership rebuilt on honest foundations. Not the old argument, which rested on scarcity and is now largely dead. A different one, which rests on the specific gap between a product that demonstrates and a product that survives.
Two Barriers, Not One
Every software company crosses two thresholds. The first is can this be built. The second is can this be run — safely, lawfully, at cost, on the devices and networks your customers actually have, without losing money or data when something fails.
For thirty years the first threshold dominated the conversation, because it was genuinely hard and because it gated everything after it. AI tools have flattened it. That is the argument of Part 1, and we stand by it.
But nothing about a large language model makes a payment reconcile, a regulator satisfied, or a 3G connection reliable. The second threshold is exactly where it has always been. The difference is that founders now arrive at it far sooner, with far more confidence, and with far less understanding of what they are looking at.
What the African Operating Environment Actually Demands
This is not a general argument about software being hard. It is a specific argument about this market. Four things reliably ambush founders here, and none of them appear in a prototype.
Regulation arrives earlier than you think
In South Africa, if your product lends money — even small amounts, even as a feature inside something else — you are a credit provider under the National Credit Act, and section 40 registration with the National Credit Regulator applies. There is no simplified track for small lenders. The threshold that founders often assume exists does not.
Hold customer funds and you are in conversation with the Financial Sector Conduct Authority. Recommend a financial product and you are inside FAIS. Handle personal information at any scale and POPIA applies — which is not GDPR with the serial numbers filed off, and which has its own requirements around operator agreements, cross-border transfer and a registered Information Officer.
None of this stops a prototype. All of it stops a launch. The cost of discovering it late is not a delay — it is a rebuild, because compliance is usually architectural rather than cosmetic.
Your users are not on your hardware
The device your product will actually run on is a low-end Android phone on a metered prepaid bundle, on a connection that drops. A JavaScript bundle that loads instantly on a laptop over fibre is a different product entirely on that phone — slow enough to be abandoned, and expensive enough that using it costs the customer real money.
This is why USSD and WhatsApp remain serious distribution channels here rather than legacy curiosities, and why offline-first is a design constraint rather than an enhancement. These are not decisions you retrofit. They shape the data model.
Infrastructure fails quietly and asymmetrically
Load-shedding is the failure everyone names. The more dangerous ones are quieter. Managed services pause after inactivity. Free tiers trip quotas. Billing accounts lapse and take compute and storage down while static hosting keeps serving perfectly.
That asymmetry is the trap. Your site returns 200. Your landing page loads. Your marketing works. And every form behind it fails silently, for as long as nobody thinks to test the thing that looks fine. Knowing that this class of failure exists — and building the check that catches it — is not something a code generator will volunteer.
Money has to reconcile
Payment integration is the part founders most consistently underestimate. Not the happy path, which is well documented and genuinely easy. The rest of it: a webhook that arrives twice, a settlement that lands days later, a refund that must survive a crash halfway through, a ledger that has to balance when a customer disputes a transaction eight weeks on.
Idempotency, reconciliation and audit trails are unglamorous, invisible to users, and the difference between a fintech and a liability.
The Demo That Cannot Become a Product
The characteristic failure of this era is not the founder who cannot build. It is the founder with a convincing demo and no path from it to a business.
The demo works because it runs once, on good hardware, on a fast connection, with the person who built it driving, using data shaped to fit. Every one of those conditions is absent in production. What closes the gap is not more code. It is judgement about which of those conditions matter most in this market, and in what order to address them.
This Is Not the Old Argument
It is worth being explicit, because the conclusion here could be misread as a retreat.
The old case for a technical co-founder was indispensability: you cannot build this without me, therefore half the company. We argued in Part 2 that this case has expired, and it has. Nothing above resurrects it.
The new case is narrower and more honest. It is not that you cannot build without them. It is that the distance between what you have built and what can be operated, in this market, is wider than it appears from where you are standing — and that closing it is a specific, learnable, scarce competence.
A narrower claim deserves a narrower share. That is precisely why the arrangement we described in Part 2 is time-boxed and milestone-linked rather than an open-ended half of the company. The argument for partnership and the argument for equal equity were always separate. Only one of them has expired.
You will also see figures claiming that teams with technical co-founders raise several times more capital. Treat them carefully. They largely measure selection rather than causation — teams that attract a strong technical partner tend to be teams that were already credible. The correlation is real. The arrow may not point the way the headline implies.
What to Look For Instead
If the value has moved from building to operating, the person you need has changed shape.
Ask for evidence of things having run, not things having been built. A GitHub profile shows what someone can make. It does not show whether they have carried something through a compliance review, a payment dispute, or a provider outage at the wrong hour.
Look for market-specific scar tissue. Someone who has integrated a South African payment service provider, been through a POPIA assessment, or shipped to feature phones knows things that do not transfer from a different market and are not in the training data.
And look for someone who will tell you what not to build. The most valuable technical input a founder receives is usually subtractive.
A Test You Can Run This Week
Put four questions to anyone proposing to join you technically. Their answers will tell you more than a CV.
- What regulation applies to this, and when does it start applying? A vague answer here is disqualifying for anything touching money, health or personal data.
- What does this cost to run at a thousand users, and at a hundred thousand? Someone who has operated will reach for numbers. Someone who has only built will reach for adjectives.
- What breaks first, and how would we know? The second half matters more than the first. Anyone can name a weak point; far fewer will have thought about detection.
- What should we not build? If they cannot answer, they are describing a service, not a partnership.
You can ask all four without being technical yourself. That is the point.
The Honest Version
African startups do not need technical co-founders because building is hard. Building is no longer hard, and pretending otherwise insults every founder who has just proved it over a weekend.
They need them because operating in this market is hard in ways that are specific, expensive to learn late, and largely invisible from the demo. Regulation that starts earlier than expected. Users on constrained hardware. Infrastructure that fails quietly. Money that has to balance.
Part 1 ended on a line worth repeating: the technical barrier has fallen, the judgement barrier has not. This is what the judgement barrier looks like up close, in this market, on the ordinary days when nothing dramatic is happening and something is quietly not working.
The question is not whether you can build it. You can. The question is whether the person beside you has seen what happens after that — and whether they have enough at stake to still be there when it does.
This is Part 3 of a three-part series. Part 1 — The Building Barrier Is Gone examines what falling technical barriers actually change. Part 2 — The Equity Split Question Nobody in African Tech Is Asking Yet sets out what a fair arrangement looks like.