The situation
A school runs three systems of record whether it admits it or not: its money, its staff, and its students. Most schools run those three in three different places, joined together by people's memory and by spreadsheets that only one person understands. The finance sits in accounting software that only the bursar sees. The staff data sits with HR or in a filing cabinet's digital equivalent. The students sit in a management information system that the school twists itself to fit.
Kristodea International School in Ghana decided to reject that arrangement. Through Evuve, my design and technology studio, I designed and built its system: one platform handling the school's finances, its staff, and its students, shaped around how this particular school already works. The build is complete.
The study matters because of what it is not. It is not an integration project and it is not a configuration of somebody else's product. It is the rarer thing: a system designed from the school's own reality, in which software finally follows the institution instead of the reverse.
The constraints
Schools are unforgiving environments for software. Term time creates hard peaks: the moments when everyone needs the system at once are precisely the moments when nobody has patience for it. The staff who use it daily are teachers and administrators, not technologists, and any friction in their day compounds across hundreds of small interactions.
The data is some of the most sensitive data that exists. Records about children, linked to finances, linked to the adults who care for and educate them. Every design decision in that model carries safeguarding and data protection weight, and the system had to treat that as a first-class design input, not a compliance checkbox.
And the deepest constraint: a school cannot pause. Whatever was built had to arrive finished enough to carry a real institution's real operations, in a world where the alternative was already running.
Discovery
The discovery work was archaeology as much as analysis. Before anything was designed, the school's real processes were mapped: how money actually moves through the institution, how staff records are actually created and changed, and how a student's life through the school actually proceeds, admission to attendance to the moments that define an education. The purpose was not to document the ideal process. It was to find where the school's reality and its records had drifted apart, because that drift is exactly where the existing software was failing.
The finding that shaped everything: the school did not have three data problems. It had one relationship problem. A student is not a row in a student table; a student is the centre of a web that reaches into staffing, into finance, and into the school's daily decisions. Any system that keeps the three domains apart, however neatly, rebuilds the very gap it was commissioned to close.
The decisions, and what was rejected
One system of record for all three domains, designed as one model. The student, the staff member and the financial record are first-class citizens of the same data model, with the relationships between them designed once, at the foundation. Rejected: three good systems joined by synchronisation, the sector's standard answer. Synchronisation is a promise to reconcile two versions of the truth, forever, and it breaks precisely on the busy day when one version matters.
The school's processes lead; the software follows. The system was shaped around how this school already works. Rejected: the market default, importing the school into a product's opinions and hoping the institution bends. Institutions do not bend. They work around software, and the work-around becomes the failure.
Design the load paths before the screens. The journeys that must not break, the first week of term, payroll days, the moments when a parent needs an answer, were mapped first and the interface drawn to serve them. Rejected: a screen-led project, which produces beautiful interfaces over structures that cannot carry the school's weight.
A teacher's day is the unit of design. Every repeated interaction was measured against the reality of a school day: between lessons, at speed, with a class in the room. Rejected: powerful interfaces with high interaction costs, which always regress to the fastest tool available, and the fastest tool available is almost always the wrong one.
Child data is designed, not merely protected. The model minimises what is held, structures access around who genuinely needs to see what, and treats every field about a child as a decision with safeguarding weight. Rejected: storing everything with permissions applied later, the pattern behind half the sector's data incidents.
The process
The build ran in the order the thinking demanded. The institution first: its processes, its peaks, its drift, mapped until the system's true shape was visible. The data model second: the three domains and their relationships designed as one foundation. The load paths third: the journeys that carry the school's weight, designed and proven before any surface existed. The interface last, drawn on top of a structure that could already carry it, which is the only order in which interfaces are actually fast to build. Then the hardest part: the transition, where a live school moves onto the system without ever stopping being a school.
Craft details
The craft in this system is mostly invisible, which is the point. One student record reaches the domains it should reach and no others, so a question that used to require three people and two systems is one answer in one place. The financial view and the people views read the same truth, because there is only one. The interface is quiet on purpose: the moments it serves are loud enough already.
The outcome, stated honestly
The school runs its finances, its staff and its students on one system built around its own reality. The three-versions-of-the-truth problem, the daily tax every institution pays when its records live apart, is designed out. The staff use a system whose shape they recognise, because it was drawn from their working life rather than imposed on it.
No invented metrics will decorate this page. The outcome is structural: a school that once needed three systems and the people who remembered their gaps now needs one, and it is theirs.
What the work taught
Most organisations do not suffer from bad software. They suffer from software that models a generic version of them. The generic version is always available, always cheaper, and always wrong in the specific places that matter. When an institution is given a system drawn from its own reality, the adoption problem largely evaporates, because there is nothing to adjust to. The adjustment was done by the software, in silence, before the first day of term. That is what design as infrastructure means.