System
School management system
One record per student, from admission to leaving certificate.
Schools are unusually hard to model because almost nothing is a simple record. A student is a person, an enrolment, a set of subject choices, a fee account, an attendance history, and a discipline file — and the rules connecting them change at term boundaries.
We build around that. The academic year, the term, and the section are first-class concepts rather than columns, so promotion, transfer, and re-enrolment are supported operations instead of migrations somebody runs by hand each July.
- Core model
- Student · Enrolment · Section · Term · Staff
- Access
- Admin, head, teacher, accounts, parent, and student roles
- Attendance
- Per period or per day, with correction trail
- Assessment
- Configurable grading schemes and report cards
- Fees
- Structures, discounts, instalments, and arrears
- Communication
- SMS, WhatsApp, and email to guardians
- Year rollover
- Promotion and re-enrolment as a supported operation
- Deployment
- Cloud or on-premise
- Devices
- Desktop for office, phone for teachers and parents
How it runs
Every stage, in order.
Each stage produces something the next one needs. Where a stage can fail, it fails visibly rather than passing bad data forward.
- 01
Admission
An enquiry becomes an application, then an enrolment, without anyone retyping the family's details.
- 02
Term
Academic year and term are structural, so timetables, fees, and results are always scoped correctly.
- 03
Daily
Attendance, substitution, and notices are the screens teachers touch every day, so they are built for a phone.
- 04
Accounts
Fee generation, receipts, and arrears run from the same enrolment record the office already maintains.
- 05
Rollover
Promotion to the next year is one reviewed operation, not a summer of spreadsheet surgery.
Scope
In detail.
Modules
16- Admissions and enquiry pipeline
- Student records and guardian details
- Enrolment, sections, and subject allocation
- Timetabling and substitution
- Attendance with correction trail
- Assessment, grading, and report cards
- Examination scheduling and seating
- Fee structures, invoicing, and receipts
- Arrears tracking and reminders
- Staff records, leave, and payroll inputs
- Discipline and pastoral notes
- Library and inventory
- Transport routes and stops
- Parent portal and notifications
- Certificates and transcripts
- Statutory and board reporting
Deliverables
What you get.
Written into the scope document before work starts, and used as the acceptance test when it finishes.
- 01Configured system covering the modules in scope
- 02Import of existing student, staff, and fee data
- 03Role and permission setup matched to the school's structure
- 04Administrator and teacher training
- 05Documentation and handover
- 06Support agreement with a defined response time
Questions
Asked before.
Can it handle our fee structure? It is complicated.
Fee structures are configuration: per class, per category, sibling and staff discounts, scholarships, instalments, and late fees. Complicated is the normal case.
What about the data in our current spreadsheets?
Importing it is part of the project. It is also usually where the real state of the records becomes visible, which is uncomfortable but useful.
Do parents need to install an app?
No. Notifications go over SMS, WhatsApp, or email, and the parent portal runs in a browser.
Can it run if the internet drops?
On-premise deployment is supported where connectivity is genuinely unreliable.
Also in Systems
Next step
Scope it before you commit to it.
The first step is a short written scope: fields, volume, schedule, delivery, and acceptance criteria. It is quick, it is concrete, and it tells you whether this is worth doing at all.