The Compound Startup Thesis for School Software

Nigerian schools don't need eight tools that talk to each other. They need one system that never needed to.

Walk into the admin office of a Nigerian secondary school at the end of term and you will find the same scene.

A class teacher has a stack of exercise books and a spreadsheet. The exam officer has a different spreadsheet, with the same student names spelled three different ways. The ICT operator is merging both into a template so that report cards can be printed by Friday.

Fees are in a ledger, or a bank app, or the bursar's head. Attendance is in a register nobody has opened since week four. Parent communication is a WhatsApp broadcast list that one person maintains and nobody backs up.

Every one of those systems works.

The problem is the space between them, and the space between them is a person, retyping.

That person is the integration layer.

When people talk about school software being "fragmented," this is what fragmentation actually means. Not incompatible APIs, but a human being copying a student's name from one screen to another and occasionally getting it wrong.

The cost is not paid in licence fees. It is paid in the last two weeks of every term.

The shape the market allows

There is a well-worn playbook for building software companies: pick one sharp problem, solve it better than anyone, and integrate with everything else.

Be the best attendance app. Let the customer assemble the rest.

That playbook assumes a customer who will assemble the rest. Someone with a budget for multiple vendors, a person whose job includes evaluating them, and the appetite to maintain integrations between them.

Enterprise software in mature markets often has that customer.

A 400-pupil school in Ibadan usually does not.

Ask a proprietor to buy an attendance product, a reporting product, a fees product, a communications product, and a lesson-planning product, each with its own subscription, login, training, support process, and data model, and the conversation can end before the demo does.

Not because the products are bad.

Because the arithmetic is difficult to justify, and the operational overhead eventually lands on an ICT operator who already has a full job.

So the point-solution playbook doesn't fail here for philosophical reasons. It often fails at the point of sale, and even when it survives the sale, the integration burden remains.

What's left is the compound approach: build multiple products as one system, around the same underlying records and shared infrastructure.

Parker Conrad popularised the "compound startup" argument in the context of HR and payroll: shared infrastructure and a common data model can make building multiple products an advantage rather than a distraction.

We arrived at a similar conclusion from a very different direction.

In Nigerian education, the customer economics almost force it.

The compound model isn't simply a strategy for selling more software. In much of this market, it is the shape that best matches how schools actually buy and operate software.

One record, or the illusion of one record

The compound argument is easy to say and easy to fake.

Plenty of "all-in-one" platforms are really several products sharing a logo and a login page. You can spot the problem quickly: the student exists four times, and changing a surname in one module doesn't change it in the others.

The real version is boring and structural.

There is one canonical learner identity.

That doesn't mean one giant database table where every piece of information about a student lives forever. It means every part of the platform agrees on who the student is.

Modules can own their own domain state and evolve independently, but none gets to invent another version of the learner.

Attendance is not a separate application that happens to contain student names. It records attendance against the learner and class relationships the platform already understands.

A term report is not an export assembled from a reporting tool. It is a view over assessments, remarks, attendance, classes, teachers, and terms that already exist in the system.

A message to a parent resolves through the same learner and guardian relationships used elsewhere.

Fees are owed by an identified learner account, not by a name that happens to match a row in another spreadsheet.

Once that foundation holds, things that are difficult elsewhere stop being integrations and start becoming consequences of the architecture:

• A report card can carry attendance because attendance was never trapped in another system.
• A parent can see their child's results because the guardian relationship already exists, rather than being recreated as a mailing list.
• A teacher's lesson notes, class list, assessments, and timetable refer to the same academic structures.
• A school group or government authority can operate across institutions because a school can become a scope over shared primitives rather than an entirely separate product.

None of those required us to build an integration between products.

They required us not to create an unnecessary boundary in the first place.

Compound is slower, until it is much faster

Here is the part that makes the approach genuinely difficult, and one of the reasons teams talk themselves out of it.

The first product built this way can be slower to ship than the point-solution version.

You are thinking about identity, tenancy, permissions, notifications, auditability, storage, and domain boundaries while a competitor can build an attendance application, hardcode most of those decisions, and have something that demos beautifully next month.

The return arrives later.

When identity, access control, notifications, audit infrastructure, and core domain services already exist, a new product does not begin from zero.

More importantly, it inherits context.

A standalone product has to justify its own identity integration, permission model, notifications, onboarding, support surface, and data synchronisation. In a compound system, much of that cost has already been paid.

The new product also knows things.

It knows who the student is.

It knows which class they belong to.

It knows who teaches that class.

It knows which guardian is allowed to see their information.

It knows which institution owns the record and which administrator has authority over it.

That shared context is ultimately more valuable than simply sharing code.

This is the real compound effect.

The first product pays for infrastructure that the second can reuse. The second introduces capabilities that the third can consume. Each additional surface makes the underlying platform more useful.

Breadth stops being purely a cost multiplier and begins to become a cost divider.

A company that gets this right should be able to ship its eighth product faster than its first.

That sounds like a violation of how software normally works.

It is really the consequence of having built the substrate before the surface.

What it looks like from the school's side

The technical argument only matters because of what it does to the school's experience.

A school doesn't evaluate our data model.

It evaluates whether the end of term is still a crisis.

The compound version changes that in ways that are specific and mostly unglamorous.

The ICT operator stops being a merge tool.

The exam officer stops reconciling different spellings of the same student's name.

Teachers stop entering the same information into multiple systems.

Parents receive information derived from the same records the school itself is using.

Reports become outputs of a living academic record rather than documents assembled from disconnected files.

One of the ICT operators using Olareport put it more plainly than any positioning statement we could write:

"It has reduced our workload by more than half."

Not because any single feature was revolutionary.

A large part of the value came from removing the work between features.

That is also why we started where we did.

We didn't begin by selling schools an "Education Operating System."

We began with report cards.

Report generation was a sharp, recurring pain. It happened every term, consumed enormous amounts of staff time, and had an obvious definition of success: reports that previously took days of manual work should not take days of manual work.

Solve that well enough and you earn the right to solve the adjacent problem.

Reporting leads naturally into assessments.

Assessments depend on classes, subjects, teachers, students, and terms.

Those same relationships make attendance useful.

Attendance makes the student record richer.

The same record becomes useful for parent communication, analytics, transcripts, and other workflows.

The wedge expands because the underlying record expands.

Compound doesn't mean launching eight products on day one.

It means building the first one so the next seven don't have to start over.

The costs, honestly

Anyone selling this approach without naming its costs hasn't run it.

Shared infrastructure creates shared consequences.

A change to a core learner abstraction can affect reporting, attendance, communication, analytics, mobile clients, internal tooling, and anything else that depends on it.

Migrations become coordination problems rather than purely local decisions.

Shared test infrastructure can mean a slow test suite taxes multiple teams.

An innocent-looking change to the student record can have a much larger blast radius than the engineer making it initially expects.

And the more products share a substrate, the more expensive the wrong abstraction becomes.

Duplication creates local complexity.

Sharing creates coordination complexity.

The engineering problem is deciding which concepts deserve to become platform primitives and which should remain inside their domains.

Get that decision right and every product built afterwards benefits.

Get it wrong and the mistake compounds too.

We would pay most of those costs again.

The parts we would revisit are mostly about sequencing: deciding which shared pieces genuinely needed to exist before the second product, and which we built early because we anticipated needing them later.

Building for reuse is valuable.

Building abstractions for hypothetical futures is still overengineering.

The difficult part is knowing the difference.

The bet

The compound thesis ultimately reduces to a claim about where complexity should live.

Point solutions push integration complexity outward onto the customer.

In this market, "the customer" eventually becomes a teacher, bursar, exam officer, administrator, or ICT operator sitting in front of a spreadsheet.

They become the API.

We would rather absorb that complexity into the platform and solve it once.

That means accepting harder engineering problems around identity, permissions, shared domain models, tenancy, migrations, and coordination.

But those are problems we can solve in software.

A school shouldn't have to solve them every term with copy and paste.

In a market with the budget and staff to operate six vendors, the compound model can be a strategic preference.

In much of the education market we're building for, it is closer to an architectural consequence of how institutions actually operate.

Schools here don't need eight tools that talk to each other.

They need one that never needed to.