The most successful school-management system ever built has no logo, no
onboarding flow, and no sales team. It is the spreadsheet. Before any of us showed
up with a product, a school's timetable, its fee ledger, its mark sheets, and its
staff list already lived in a grid of cells that someone maintained by hand. If
you want to build software schools actually adopt, the first thing to do is stop
treating the spreadsheet as the enemy and start treating it as the incumbent that
beat everyone else.

I say this with respect, because the spreadsheet earns its place. It is the rare
tool that does almost everything a small institution needs and asks almost nothing
in return.

What the spreadsheet gets right

When I look at why a deputy head still keeps the term's data in a workbook rather
than the system we sold them, the reasons are always the same, and they are good
reasons:

• It is infinitely flexible. A new column appears the moment a new question does. No feature request, no waiting for a release. The data model bends to the school instead of the other way around.
• It is owned. The file sits on a laptop, a phone, a flash drive. Nobody can switch it off, raise the price, or lock the school out at the end of a term.
• It is legible. Anyone who has used a phone can read a grid. There is no hidden logic, no mysterious state — what you see is the whole truth.
• It is forgiving. You can fix a mistake by typing over it. You can keep last year's version in another tab. It tolerates the messy, improvised way real institutions actually work.

Most software I have seen fail in a school failed not because it did less than a
spreadsheet, but because it did less flexibly. It was more rigid, more
opinionated, and more eager to own the data than the people who depended on that
data were comfortable with.

Replacing a spreadsheet without insulting it

So the bar is not "be more powerful than a spreadsheet." Spreadsheets are nearly
infinitely powerful in the small. The bar is "be worth giving up that power for."
Software earns that trade only when it removes a specific pain the grid cannot —
the formula that breaks silently when a row is inserted, the version that gets
emailed around until nobody knows which is current, the moment two people edit the
same file and one of them loses an afternoon of work.

That has shaped how I build. I assume the spreadsheet is what I am really
competing with, and I design accordingly: let people import their existing file on
day one instead of re-typing a term of data; always allow a clean export, so the
school never feels trapped; keep the data model close to the mental model the
staff already hold; and earn one piece of trust at a time rather than demanding
the whole institution migrate at once.

The goal is not to win an argument against the spreadsheet. It is to be the thing
a tired administrator reaches for first because, in the one place it counts, it
hurts less. Until software clears that bar, the grid will keep winning — and
honestly, it deserves to.

Joan Urevbu (Joan Osunde) is a technologist and writer focused on education. She
builds the unglamorous, high-stakes software that decides whether a parent gets
the message and a school day starts on time — timetabling, gate logistics, and
messaging systems built for low-bandwidth, high-trust environments. Working
between Benin City, Nigeria and Porto Alegre, Brazil, she writes about building
technology for African education. More at joanurevbu.com.