Admissions data re-typed into the student record, then again into the fee ledger
Admissions, records and fees in one place.
Most schools run on a registrar's spreadsheet, a bursar's ledger and a WhatsApp group for parents. It holds until an audit, a fee reconciliation or a departure.
The questions we’d open with
A first meeting is not a demo. It is these four questions and a notebook.
If you can answer them off the top of your head, you probably don’t need us yet. If answering them means asking three people and opening two files, that gap is the thing we build against.
- How do you manage student records, admissions and fee collection today?
- What reporting challenges come up at the end of a term?
- Who re-keys data between admissions, records and the bursary?
- What happens when a parent disputes a payment?
What it usually looks like first
01
02
Fee reconciliation done by hand against bank statements at term end
03
No single answer to “how many students are enrolled right now”
04
Reports to the board or the Ministry assembled from three files
None of this means the operation is badly run. It means the operation outgrew the tools that were right for it three years ago. That is a different problem, and a cheaper one to fix.
Where we start
Usually the fee ledger: one record per student, payments matched automatically, and a balance the bursary and the parent both see.
We ship in slices rather than in one release. Something useful reaches real users within weeks of the design being agreed, and grows from there. You see whether it works before the bill gets large.
01
Map
02
Design
03
Build
04
Adopt
05
Run
What we usually build for education
Who we talk to
Private schools, universities, edtech companies
Where we meet
- Education conferences
- PTA networks
- Ministry of Education connections
Start with the walkthrough, not the demo.
An hour on site, the four questions above, and an honest answer about whether a build is warranted. It costs nothing.