DEV Community: Joan Urevbu

Why Schools Still Run on Spreadsheets

Joan Urevbu — Thu, 18 Jun 2026 12:20:40 +0000

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.

Designing for the Last Bar of Signal

Joan Urevbu — Thu, 18 Jun 2026 12:14:58 +0000

There's a design assumption baked into most modern software that I've had to
unlearn: that the network is there. That it's fast, cheap, and always on. Build
between Benin City and Porto Alegre for long enough and you stop believing it.

When you build for places where data costs real money and connectivity comes and
goes, you start designing for the last bar of signal — the moment when the
connection is weakest, not strongest. That single shift changes almost every
decision.

The message has to land, not just send

In a well-connected world, "we sent it" and "they got it" are nearly the same
sentence. In a low-bandwidth world they are completely different claims. A push
notification needs an installed app, an open data connection, and a user who
opens the app. Each of those is a place the message can quietly die.

That's why I lean on channels that degrade gracefully:

SMS reaches any phone, no app, no data. It's the floor that never drops.
Plain text and small payloads load on a weak connection where a heavy page never finishes.
Delivery receipts, where you can get them, turn "sent" into "arrived" — the only number that actually matters.

Small is a feature, not a limitation

A 2-megabyte page isn't "rich." On a metered, intermittent connection it's a
toll booth. Every image, every script, every font is something the user pays for
in money and patience. Designing small — fewer assets, lighter pages, text that
survives compression — isn't austerity. It's respect. It says: I know what this
costs you, and I've kept it cheap.

The same goes for resilience. Can the task be finished if the connection drops
halfway? Can it be retried without doing damage? Can a non-technical person tell
whether it worked? In a low-bandwidth context these aren't edge cases. They're
the main case.

Why this matters beyond convenience

It's easy to frame low-bandwidth design as a niche constraint. It isn't. It's how
a large share of the world actually comes online — on phones, on mobile data, in
bursts. When we design only for the fast, cheap, always-on network, we quietly
build for the people who already have the most and leave out the people a school,
a clinic, or a public service most needs to reach.

Designing for the last bar of signal is, in the end, just designing for everyone
honestly — including the people whose connection is the worst on the day it
matters most.

The Best School Software Is Invisible

Joan Urevbu — Thu, 18 Jun 2026 12:14:53 +0000

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.