The first meeting with this client wasn't about software. It was about a filing cabinet.
That's a slight exaggeration, but not by much. The administrator we met with — we're not naming the institution here, at their request, though the work itself is real and recent — walked us through how the school actually ran day to day, and most of it lived in places that had nothing to do with each other. Attendance was tracked on paper registers, one per class, collected by hand at the end of each term. Fee payments were tracked in a spreadsheet that one person maintained, updated whenever parents paid at the school's bank branch and brought back a teller. Exam results were compiled manually by each subject teacher, handed to a form master, and eventually typed into report cards by a staff member who did this for the entire school, every term, over what she described to us as "about three very long weeks."
None of these systems were broken, exactly. They'd worked, in the sense that the school had been running this way for years. What had changed was scale. The school had grown past the point where informal, manual processes could keep up without real strain — more students, more staff, more parents asking questions the current system couldn't answer quickly, like "why hasn't my child's fee payment been reflected" or "can I see my child's attendance for this term." The administrator's actual ask, once we got past the filing-cabinet description of the problem, was simple to state and considerably harder to build: one system that could handle admissions, attendance, fees, and results, that non-technical staff could actually use without extensive retraining, and that wouldn't require reliable high-speed internet to function, given the realities of connectivity at the school's location.
Scoping This Honestly, Not Ambitiously
The instinct on a project like this — and we'll be honest that it was our instinct too, initially — is to design something comprehensive from day one. A school management system touches almost every part of how an institution runs, and it's tempting to try to solve all of it in one build. We didn't do that, and it's worth explaining why, because it's the decision that shaped everything that followed.
We scoped this in four modules, built and rolled out in sequence rather than all at once: student and admissions records first, attendance second, fee tracking third, and results and report card generation last. This wasn't just good project management — it was a direct response to something the administrator told us in that first meeting, almost in passing: staff at the school were not confident with technology, and a system that asked them to change everything about how they worked, all at once, was more likely to be quietly abandoned within a term than adopted. Rolling out one module at a time meant staff could build confidence and habit with something manageable before the next piece arrived, and it meant we could genuinely learn from how the first module was actually used — not how we assumed it would be used — before building the next one.
What Actually Turned Out to Be Hard
The technically interesting part of this project wasn't the parts that sound complex on paper — the database structure connecting students to classes, guardians, fee records, and results was fairly standard relational design, nothing exotic. What turned out to be genuinely difficult was building for staff who had never used software like this before, in an environment where internet connectivity wasn't something we could assume would be reliable during school hours.
We built the system to work offline for core daily tasks — a class teacher taking attendance shouldn't need a stable connection to mark a register — with data syncing back to the central system once connectivity was available. This added real complexity to the build, particularly around handling conflicts if the same record got edited in two places before a sync happened, but it was a non-negotiable requirement once we understood the actual conditions the system would be used in. A school management system that only works when the internet is perfect isn't a school management system for most Nigerian schools — it's a demo.
The other genuinely hard part was the report card generation module, which sounds like the simplest piece and turned out to be the most involved. Every school has its own grading conventions, its own report card format, its own rules about how continuous assessment scores combine with exam scores, and this institution was no exception — their format had specific conventions built up over years that the staff considered non-negotiable, reasonably so, since parents were used to reading results in that exact layout. Building flexible enough grading logic to match an existing, specific format, rather than pushing the school toward a generic template, took considerably more back-and-forth with the academic staff than we'd initially scoped for.
The Training Problem Nobody Budgets For
We'll say this plainly, because it's a pattern worth other institutions hearing before they commission something similar: the software being finished is not the same as the software being adopted, and the gap between those two things is almost entirely about training and support in the weeks immediately after each module goes live. We ran hands-on sessions with the specific staff who'd use each module — the bursary staff for fees, class teachers for attendance, subject teachers and the exams officer for results — rather than one general training session for everyone, because the questions a bursary officer needs answered are genuinely different from the questions a class teacher needs answered, and mixing them into one generic session tends to leave everyone half-served.
We also stayed reachable — by phone, by WhatsApp — for direct, immediate support in the first few weeks after each rollout, specifically because we'd seen, on earlier projects, how quickly staff revert to the old paper-based habit if their first frustrating experience with new software doesn't get resolved quickly. A staff member who hits a confusing screen on day two and can't get a fast answer will quietly go back to the paper register by day three, and once that reversion happens, it's considerably harder to bring them back than it would have been to just solve the day-two problem promptly.
Where This Stands Now
The system has been in full use for two terms as of this writing, across all four modules. Report card generation, which used to take the exams officer roughly three weeks each term, now takes a few days — most of that time is teachers entering scores, not the system processing them. Fee tracking is visible to the bursary in real time instead of reconciled from paper receipts after the fact, and the school has started fielding fewer of the "has my payment been received" questions from parents that used to eat up staff time. Attendance data that used to live in paper registers, functionally unusable for anything beyond the immediate term, now exists as a searchable record the school can actually analyze — patterns of absence, for instance, that weren't visible before simply because nobody had the time to compile them by hand across a full term.
We won't pretend everything went smoothly. There were staff who took longer than others to get comfortable, a few weeks of the offline sync behaving in ways we hadn't fully anticipated in testing, and one grading-logic edge case in the results module that took longer to resolve properly than anyone was happy about at the time. What made the project work, in the end, wasn't a flawless build. It was scoping it around how the school actually operated rather than how a generic school management system assumes schools operate, and treating the rollout and training as seriously as we treated the code itself.
