Nobody has ever sent me a thank-you note for a register that added up.
I've spent the last several years building software for schools — timetables,
teaching assignments, gate logistics, the pipelines that carry a message from a
head teacher to ten thousand parents. And the strange truth of this work is that
when it goes well, it disappears. The parent gets the text about the half-day.
The substitute teacher is in the right room by 8 a.m. The term runs. No applause,
because nothing went wrong. That silence is the product working exactly as
designed.
It took me a while to make peace with that. We're trained to want visible wins —
the slick dashboard, the feature demo that makes a room lean in. But schools
don't need theatre. They need the boring thing to happen, every single day,
without fail, for years. The measure of school software isn't how impressive it
looks in a pitch. It's whether a tired administrator at the end of a long term
still trusts it enough not to keep a backup spreadsheet "just in case."
Trust is the whole product
In most institutions, the real operating system isn't software at all. It's a
person — the deputy who knows which teacher covers which class, the secretary who
remembers which parents actually read their messages. When you build software for
a school, you are asking that person to hand part of their memory to a machine.
They will only do it if the machine is right every time. One missed message,
one timetable clash on the first day of term, and the spreadsheet comes back out
of the drawer. Trust is expensive to earn and cheap to lose.
So I optimize for the unglamorous things:
- Correctness over features. A timetable tool that's right and plain beats a beautiful one that occasionally double-books a teacher.
- Reliability over reach. A message that always arrives to 3,000 parents is worth more than a clever one that sometimes reaches 10,000.
- Recoverability. When something does break — and it will — how fast can a non-technical person fix it without calling me?
Building where the network is the hard part
A lot of education technology is designed in places with fast, cheap, always-on
internet, and it shows. It assumes apps will be downloaded, notifications will be
seen, data will be plentiful. In much of the world that's simply not true. A
parent may share one phone across a household, top up data in small amounts, and
go offline for stretches. If your only channel is a push notification inside an
app they rarely open, you haven't reached them. You've reached their lock screen.
This is why so much of my work comes back to SMS. It's old, it's unglamorous, and
it lands — on every phone, without an app, without data. Designing good SMS
systems is its own craft: how to phrase a message that survives being cut to 160
characters, how to send to thousands of numbers reliably and affordably, how to
know a message was actually delivered. None of it photographs well. All of it
matters more than the dashboard.
Why I keep doing it
Because the stakes are quietly enormous. A school that runs well gives a child a
steady day. A parent who gets the right message on time can plan their work, show
up, stay involved. The software I build will never be the reason a student
succeeds — but a hundred small failures of communication and logistics can
absolutely be the reason a system frays. I'd rather spend my career removing
those small failures one at a time than building one more thing that demos well
and breaks in the field.
The best school software is invisible. Nobody thanks the system that simply
worked. That's not a disappointment. That's the entire point.
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.
