date: "2026-04-13"
Most software gets built because someone spotted a market gap in a slide deck. Nexa Ed got built because I grew up in Nigeria, went to school there, worked in one, and watched the same avoidable problems compound for years before deciding to do something about it.
The thing about a school email
When you're a student in the US or UK, your institutional email address opens doors most people don't think twice about. GitHub Student Developer Pack. Notion for free. Adobe discounts. Figma. Notion. JetBrains. The list is long and the value is real — it's infrastructure that quietly advantages students who have it over students who don't.
Nigerian students, by and large, don't have it. Not because their schools don't care, but because provisioning and managing email accounts at scale is operationally complicated and nobody has made it easy enough to be worth the effort. So the accounts never get created, and the students never get the benefits, and the gap between what a student in Lagos can access versus a student in London quietly widens.
That bothered me growing up. It bothers me now. It's one of the two reasons Nexa Ed exists.
The scratch card
The second reason is more specific and more absurd.
In Nigeria, when exam results are processed, students pay for something called a scratch card. You buy the card, scratch off a PIN, enter it into a portal, and that's how you see your grades. Every result cycle. Every student. A physical card, purchased separately, to access information that the school already has and the student already paid fees to receive.
The cost compounds. Schools charge for result processing on top of it. The administrative overhead of managing the whole pipeline — collating paper result sheets, entering scores manually, issuing scratch cards, reconciling payments — consumes weeks of staff time per term. Teachers I worked alongside spent hours on data entry that software should have handled in minutes.
The question that kept surfacing was simple: why can't the results just be in the portal already? Admin publishes them when they're ready. Students see them immediately. No scratch card. No manual entry. No separate payment for access to your own grades.
There's no good answer to that question. It's not technically hard. It's not expensive to solve. It just hadn't been solved for this specific context.
What it looks like in practice
Working inside a school made the administrative burden concrete in a way that statistics don't. The volume of paperwork that flows through a school office on any given day — enrollment forms, fee receipts, attendance registers, result sheets, staff rosters — is staggering. And it's mostly manual, mostly duplicated, and mostly reconciled by hand at the end of each term.
Teachers tracking attendance on paper. Finance staff chasing unpaid fees across handwritten ledgers. Administrators processing results one student at a time against a spreadsheet that someone else started and nobody quite understands.
None of this is a criticism of the people doing the work. They're managing systems that were designed for a different era and haven't been replaced. The criticism is that better systems exist and haven't been brought to bear on this specific problem.
What we built
Nexa Ed targets all three of these problems directly.
For the email gap: bulk provisioning of school domain email accounts, with Google Workspace integration or Nexa-hosted subdomains, manageable by a single administrator. A school that previously had no student emails can have them created and active in an afternoon.
For the scratch card absurdity: AI-powered results processing where a school uploads their existing PDF result sheets, and the system extracts, structures, and publishes scores directly to each student's portal. No manual entry. No separate payment. No scratch card. The admin publishes when they're ready and every student sees their results immediately.
For the administrative load: a unified dashboard where fee collection, enrollment, attendance, and academic records live in one place — built specifically for how schools in this region actually operate, not as an afterthought to a product built for a different market.
Why now
The building blocks that make this tractable — reliable OCR, capable language models, real-time database infrastructure that works well on variable connectivity, Paystack for payments — have converged in the last two years in a way that makes a genuinely good product possible without an enormous engineering team.
The demand has always been there. The tooling to meet it properly is now here.
That's the combination worth building on.