School ERP
One record per student, held in one system
School administration in one system: admissions and student records through timetabling, examinations, fee ledgers and parent communication.
Why we built it
Walk into a school office in February and you can usually see the problem on the desk. Admissions in one register, fees in a second, attendance in a third, examination marks in a spreadsheet on one teacher's laptop, and parent phone numbers in whichever of the four is most recent. Every one of them is maintained carefully. None of them agrees with the others.
The cost is not the storage, it is the reconciliation. A parent asks why a fee reminder arrived for a student who paid last week, and answering takes twenty minutes and two people. A transfer certificate needs marks, attendance and a clear fee ledger, so it waits on three separate confirmations. Nobody in the building is doing anything wrong; the work is structurally duplicated.
We built this after watching that happen in school after school. The design principle is single-record: a student exists once, and admissions, attendance, examinations, fees and communication all read the same row. That is the whole idea, and most of the value follows from it.
Who it is for
Three situations this was designed around
Schools running on registers and spreadsheets
The common starting point, and the one where the difference is most immediate. Existing records are imported rather than re-entered — the migration is part of onboarding, not homework we leave with your office staff.
Groups running more than one campus
Each campus keeps its own timetable, fee structure and staff, while the group gets a consolidated view. Configuration is per campus, so one branch changing its fee schedule does not disturb another.
Schools already on software they have outgrown
Usually the complaint is that fees and academics are separate products from the same vendor, and the two never quite reconcile. That is precisely the seam this design removes.
What it actually does
- Admissions and records
- Enquiry through to enrolment as one tracked pipeline, with documents attached to the student record rather than filed separately. Staff records run alongside, sharing the same permission model, so a class teacher's access follows their assignment automatically.
- Timetabling and attendance
- Timetables per class and per teacher, with clash detection at the point of editing rather than as a report afterwards. Attendance recorded against the live timetable, which is also what makes the substitution app able to tell who is genuinely free.
- Examinations and reporting
- Assessment structures configured per board and per grade, mark entry restricted to the assigned teacher, and report cards generated from the same records that fed attendance and fees — so a transfer certificate assembles itself instead of requiring three confirmations.
- Fees, receipts and reconciliation
- Fee heads, schedules, concessions and instalments, with a ledger per student that shows what was billed, what was paid and what remains. Receipts issued against the ledger, and reconciliation designed for the case that actually happens: partial payments, cash at the counter, and corrections after the fact.
- Communication with a delivery record
- Announcements and per-student messages to parents, kept against the student record with a delivery log. The log matters more than the sending: 'we did inform you' is a conversation schools have regularly, and it should not depend on memory.
At a glance
- Admissions, student records and staff records
- Timetabling, attendance and examination workflows
- Fee collection with receipts, ledgers and reconciliation
- Parent and teacher messaging with delivery records
- Role-based access across admin, staff and parent accounts
Questions we get asked
Can you migrate our existing records?
Yes, and it is part of onboarding rather than something we hand back to your staff. Spreadsheets, exports from a previous system and paper registers all get imported. We reconcile the result against your own numbers before go-live, because the first month is when trust in a new system is either established or lost.
Do parents need to install an app?
No. Parent communication reaches them without requiring an install, which matters because install rates among parents are low and uneven, and a system only some parents receive is worse than one everybody does.
How is our data separated from other schools?
Each school's data is isolated at the query layer rather than by application convention, and access within a school is role-based — a class teacher sees their classes, not the whole school. This is the same isolation work described on our SaaS engineering page; we run our own product on it.
What does support look like after go-live?
You talk to the team that built it. There is no separate support tier reading from a script, and the first term after go-live is when we expect the most contact — that is normal and it is priced in rather than treated as an exception.
Can it work alongside the substitution app?
That is the intended arrangement. The substitution app reads the same live timetable and attendance records, which is what lets it work out real availability rather than asking someone to check. Either can run on its own, but together neither needs data entered twice.
Our other product
See School ERP against your own data
Send a sample timetable or fee structure and we will demo with that rather than with a prepared dataset.