The "missing middle" — why African software stops at the MVP and Shenzhen does not.

Across the continent, the same pattern keeps showing up. A team builds an MVP in six months. They get a grant or a pre-seed. They demo well. They sign a few pilots. Then they hit the year-eighteen wall and the product never makes the jump from prototype to platform. The metric I watch is operational headcount per thousand users; in healthy products it is flat or declining. In African startups it is climbing through the prototype phase and never recovers.

The missing middle is the layer of engineering work that turns a working MVP into a system that can be operated by people who did not write it. Continuous integration. Monitoring. Runbooks. Schema migrations that do not require the founding engineer in the loop. Cost controls. Multi-region failover that actually fails over. Real onboarding for the second cohort of engineers, not just the first.

Most African startups skip that layer. Not out of malice or ignorance. Out of optimism — the belief that the team that shipped the MVP will be the team forever. They will not be. The second product cycle is always handed off, and the system has to survive that handoff.

Now look at Shenzhen.

A Shenzhen hardware-and-software startup goes through a loop nobody in Silicon Valley quite has. Idea on Monday. Schematics on Tuesday. Prototype off the line on Friday. Beta units to operators on the following Monday. Iteration on the following Friday. The loop is so tight that the engineering team treats the MVP as throwaway by design. The product is the manufacturing process and the operational data pipeline that supports it.

That is the discipline the African ecosystem is missing. Not the speed — African teams ship fast. The instinct that the production system is its own product, with its own engineering, its own metrics, and its own roadmap.

There are four pieces of the missing middle that, in my experience, are the highest leverage to fix first.

One — observability before features. Wire metrics, logs, traces, and alerting into the system before you add the second feature, not after the tenth. The cost of doing this on day one is a single sprint. The cost of doing it after the system has eighty thousand users is a quarter of engineering capacity.

Two — schema migrations as a discipline. Most outages I have audited in African startups trace back to a schema change that was done manually, in production, by the engineer who wrote the table. Adopt a migration tool. Adopt a code review process for every migration. Treat the database as code.

Three — runbooks and on-call. If the system cannot be operated by a junior engineer reading a document on Saturday night, it is not a product. It is a hobby. Write the runbook before the founder leaves for a conference, not after the outage.

Four — cost telemetry. Cloud costs in African startups are often double what they should be because nobody is watching the bill. The fix is a thirty-minute dashboard plus an alert. The savings compound for the life of the company.

None of this looks like product work. All of it is the difference between a prototype and a product. Shenzhen learned this lesson at the level of the city itself — the production line is the moat. African software has to learn the same lesson, faster, and at the level of the company.

The MVP is not the win. The system that survives the second engineering team is the win.