“Building for Africa” is a phrase that can mean almost nothing if it is not examined.
Used carelessly, it treats a continent of many countries, regulatory systems, languages, education structures and economic conditions as a single market with a single set of needs. That framing is convenient for a pitch deck. It is a poor foundation for a product.
The more accurate starting point is that African institutions have a great deal in common and differ in ways that matter enormously — and that a platform intended to serve them has to be built for both facts at once.
Where the differences actually sit
Some of the variation is obvious. Different countries have different regulators, different qualification frameworks and different requirements for how outcomes are recorded and reported. A qualification structure that is standard in one market has no direct equivalent in another.
Some of it is less obvious and more consequential.
Institutions vary in capacity. A well-resourced institution with dedicated IT staff and a small training provider run by three people are both legitimate customers with the same underlying need, and they cannot be onboarded, supported or priced identically.
They vary in operating conditions. Connectivity, power reliability and device availability differ not only between countries but between campuses within the same institution.
They vary in what they already have. Some are replacing paper. Some are replacing a system that works but is expensive. Some are integrating with something they cannot replace at all.
And they vary in what they are accountable for. A professional body’s obligations are not a college’s obligations, which are not a school’s, which are not those of an industry skills-development provider.
Serving institutions in South Africa, Namibia, Zimbabwe and the United Kingdom has made this concrete rather than theoretical. The commonality across those markets is real — institutions everywhere need to enrol, teach, assess, record, comply and report. The specifics of how are not transferable.
The two failure modes
There are two straightforward ways to get this wrong, and both are common.
The rigid build. A single opinionated system that assumes every institution operates the way the first few customers did. It is efficient to develop and demonstrates well. It fails at the second market, or the second institution type, when a requirement appears that the model cannot express. What follows is usually a special case, then another, then a codebase where nobody can safely change anything.
The infinite build. A system so configurable that every deployment is effectively a bespoke project. It can serve anyone, which sounds like an advantage until you look at the economics: implementation costs stay high, support becomes unaffordable, and each customer runs a slightly different product. This is how a software company quietly becomes a consultancy.
The first fails on adaptability. The second fails on scale. Both are avoidable, and avoiding them is largely a question of deciding — deliberately and early — what is genuinely common and what must vary.
Deciding what is common
This is the central architectural judgement, and it is more product decision than technical one.
Some things are structurally the same everywhere: there are learners, there are programmes of study, there are assessments, there are outcomes, there are records with authority and history, there are people permitted to act on them. That layer should be shared, stable and hard to change, because everything else depends on it.
Other things are legitimately local: what a qualification is composed of, what an approval chain looks like, what must be reported to whom and in what format, what terminology the institution uses. That layer must be configurable, because dictating it means being adopted only where the guess happened to be right.
The mistake to avoid is drawing the line by convenience. If something varies between real institutions, encoding it in the core model creates a future rewrite. If something genuinely does not vary, making it configurable adds a decision to every deployment for no benefit.
Getting that boundary right is most of the work. Getting it wrong is expensive in a way that is not immediately visible.
Diversity of condition, not only of requirement
Requirements are the visible half of the problem. Operating conditions are the half more often ignored.
An institution’s ability to use a system depends on more than whether the system supports its qualification structure. It depends on whether it works on the devices staff actually have, on the connection actually available, at the moment of highest load — enrolment, assessment, results.
Designing for that means treating affordability, resilience, offline capability and usability as architectural requirements rather than later refinements. It is the same argument I would make about offline-first: build for the harder condition and the easier one is inherited, not the reverse.
There is also a pricing dimension that technology strategy discussions tend to skip. A platform priced for the best-resourced institutions will be adopted by the best-resourced institutions. If the ambition is to serve the sector rather than its upper tier, affordability is a design constraint that reaches back into architecture — into how efficiently the system runs, how much support each deployment requires, and how much of onboarding can be done without a project team.
Scale, properly understood
Scale in this context is not primarily about handling volume. It is about how the cost of serving the next institution behaves.
A platform scales when the hundredth deployment is cheaper and faster than the tenth — because the common layer holds, because configuration replaces custom development, because support draws on the same knowledge each time. It does not scale when each new institution adds permanent complexity, regardless of how many users it can technically handle.
That is why “build once, adapt intelligently, scale responsibly” is an operational discipline rather than a slogan. Build once: one architecture, one system of record. Adapt intelligently: configuration where institutions genuinely differ, not everywhere. Scale responsibly: at a pace where each new market is properly understood before it is entered.
The last part matters. Expanding into a market whose regulatory and institutional realities you have not learned produces the special-case problem at speed. Preparing for expansion into West and East Africa means understanding those environments first, not assuming that what works in one market transfers whole.
What this asks of the people building
The technical implications are demanding, but the harder requirement is a habit of mind.
It means treating every institution’s context as information rather than as an exception to be minimised. It means resisting the pull to generalise from the customers you happen to have. It means being willing to say that a request is genuinely local and should be configured rather than built into the core — and equally willing to recognise when a pattern has appeared often enough that it belongs in the shared layer.
Mostly it means accepting that a continent-scale strategy is not one product decision repeated. It is a common foundation with real capacity to accommodate difference.
Africa does not need imported assumptions about how its institutions work. It needs technology built for the conditions and ambitions that are actually here — which is a harder engineering problem than building for a single market, and a considerably more valuable one to solve.