What a real school management system includes — the complete module checklist
When someone briefs a school management system — to a dev team or an AI agent — the scope goes wrong in one of two directions. Either they cram in every module a vendor's marketing page lists and ship a bloated, half-finished mess, or they miss a load-bearing piece and discover in week three that the thing can't actually run a school.
This is the checklist we wish people started from. It's not "a list of features" — anyone can list features. It's what each module has to actually do to survive a real school, in roughly the order you should build them, with the line drawn clearly between the core (non-negotiable) and the optional ERP layer (defer until a customer names it).
The core modules — non-negotiable, in build order
These aren't optional and they aren't independent. Build them in this order, because each one depends on the model underneath it.
1. Foundation, roles & permissions
The control plane. Five roles cover most single-school builds, and they must differ meaningfully — not the same screens with buttons hidden:
| Role | Lives in | Must not reach |
|---|---|---|
| Admin / Principal | Everything; the control center | — |
| Teacher | Their classes: attendance, marks, homework | Other classes, finance |
| Accountant / Front office | Fees, invoices, admissions | Marks, exam internals |
| Student | Own timetable, results, dues | Anyone else's records |
| Guardian | Their children only | Other students entirely |
Every permission must be enforced at the data layer — scope each query to the institution and role — not just by hiding UI. Build the admin portal first; it's where everything is configured.
2. Student information (SIS) — with a real guardian model
The student record is the spine. The mistake here is fatal and common: storing guardians as text on the student. A guardian is a separate entity with a many-to-many link to students (siblings share a guardian; a child has multiple guardians), a relationship type, a primary-contact flag, and messaging consent. Get this right and admissions, communication, and fees all have something solid to attach to.
3. Admissions / enrolment
How students get into the system — the messy real-world intake, not just a "create student" form. Enquiry, application, document collection, admission number assignment, class allocation. For many schools this is a seasonal, high-pressure workflow, and it's where the front office's opinion of the software is formed.
4. Attendance
The highest-frequency task in the building, done every period by every teacher. The spec that matters isn't "record attendance" — it's record a full class in one or two clicks, keyboard-friendly, with corrections allowed. Per-period and per-day models differ by institution; pick the one your school actually uses. Slow attendance is the single fastest way to lose the staff.
5. Timetable & calendar
Classes, sections, periods, terms, holidays. It feeds attendance, exams, and the teacher's and student's daily views. It doesn't need to be a constraint-solving auto-scheduler in v1 — but it needs to model the real structure of the school week.
6. Curriculum, homework & assignments
What's being taught, what's due. Lighter than the others, but it's where the teacher–student–parent loop happens day to day, so the parent-visibility piece matters.
7. Exams, assessment & results
The trap here is hardcoding one grading scheme. Schools grade with percentages, letter grades, GPA, CWA, competency bands — and a single school may use different schemes for different sections. Model the grading scheme as configurable data, not as logic baked into the code. Results then flow to report cards and to the parent portal.
8. Fees & finance
The accountant's home, and a small billing engine in its own right. It needs fee structures (per class, per year), components (tuition, transport, lab), installments (the term schedule), concessions (scholarships, sibling and staff discounts, with reason and approver), invoices, and payments (with method, date, and who recorded it). A flat "amount due" is not a fee system — it's a placeholder you'll rip out the first week.
9. Communication
Announcements and targeted messaging — to a class, a section, all guardians of a grade, individuals. This is the module that proves the guardian model from step 2: if you can't query "all primary guardians of Grade 7 who consented to SMS," your contact model is wrong.
10. Parent portal — mobile-first
Not a module bolted on at the end; a first-class, mobile surface. Attendance, results, fees due and payment, announcements, homework. A phone is the only device most parents will ever use, so this is a mobile spec, not a desktop screen shrunk down.
The optional ERP layer — powerful, and almost always premature
These show up in larger deployments and are easy to want because they make the module list look complete. They almost never belong in a first delivery. Build each only when a specific customer names it:
- Transport / route management — stops, routes, vehicle assignment, optional GPS.
- Hostel / boarding — room allocation, mess, leave management.
- Library — catalog, issue/return, fines.
- HR & payroll — staff records, salary, leave.
- Inventory / assets — stock, asset registers.
- LMS-style content delivery — if the school wants online learning, that's its own product surface.
The discipline that separates a shippable system from a bloated one is saying no to these by default and adding them as explicit, scoped decisions — never as "while we're at it."
The cross-cutting concerns that decide whether the school keeps it
These aren't modules you can point at in a demo, but they're the difference between software a school adopts and software it quietly abandons:
- An import center that validates. Schools arrive with years of messy data. Reject bad rows, log every error, let the admin fix and re-run. Migration is a project phase, not a button.
- The academic year as a first-class concept. Promotion, rollover, re-admission, alumni. The system has to survive year-end, every year.
- Reports the school actually needs. Defaulter lists, attendance summaries, collection by class, board-ready summaries — derived from live records, not a drifting denormalized copy. The tell: ask which report they export to Excel today.
- Audit trails on the things that matter — fee concessions, grade changes, who recorded a payment. Schools handle money and minors; "who changed this" is not optional.
- Click-depth discipline on the daily loop, enforced as a design rule, not an afterthought.
Two things this checklist deliberately does not settle. If you are not certain whether you need a system of record or a course-delivery platform, student information system draws the SIS-versus-LMS line and covers the guardian data model that decides whether a parent portal is even possible. And if the question is where it runs and who can reach a child's record, web-based student information system covers hosting, the permission matrix and migration.
How to use this checklist
Scope is a series of explicit include / defer / skip decisions made before any code — institution type, which core modules in v1, which optional modules deferred, which grading scheme, which fee structure. Made up front, those decisions keep the optional layer from bleeding into the foundation. Made implicitly, by an agent guessing, you get the bloated-and-hollow system that fails QA.
That's exactly what the School Management planner does: it walks your coding agent through this checklist the way someone who's built these would, with the core above as the spine and the optional layer fenced off until you ask. For the failure modes this prevents, see what breaks when you build one; for the build sequence, how to build one without shipping a toy. Or just see a real one a planner built and click through exactly what's in it.