Product Overview

SkoolyHub is a school management system: one deployment runs one school's academics, admissions, people, attendance, money, assessment and communication, plus the public website and the REST API behind the parent, teacher and student apps.

Who it is for

The design decisions that shape everything

One install, one school. There is no school_id anywhere. Multi-school operators run one deployment per school, which keeps every query simple and makes a data leak between schools structurally impossible rather than a matter of remembering a WHERE clause.

The academic year is the scoping key. Classes, sections, timetables, fee structures, exams and enrolment all hang off academic_year_id. Rolling over to a new year is an explicit operation (Students → Promote / Roll Over), not an implicit date change, so last year's records stay exactly as they were.

Money is in minor units. Every amount is an integer number of cents, in the database and in transit. Columns say _cents. No float ever touches money.

Nothing about a child is visible to the wrong adult. Parent endpoints resolve the caller's own children and scope every query to them; teacher endpoints scope to the sections that teacher covers. Ids in URLs are opaque, not sequential. Tokens carry their role, so a parent token replayed against a teacher route is a 401.

Results are invisible until published. A report card requires both its own publish flag and its exam's. Publishing is always a separate, deliberate action from entering marks, because publishing is what notifies families.

Never trust a client amount. Fee payments are recomputed from the invoice; marks are clamped to the paper's maximum; grades derive from the grade scale. The request may choose options, never numbers.

Modules

Academics — academic years and terms, classes, sections, subjects and subject allocation, the bell schedule, the timetable grid with teacher and room clash detection, the school calendar, syllabus and lesson plans.

Admissions — a pipeline from enquiry → applied → assessment → offered → accepted → enrolled, with waiting lists and rejections. Converting an accepted application creates the student and links or reuses the family's guardian account, which is what stops a second sibling generating a duplicate login.

Students & guardians — the roll, enrolment history, documents, ID-card printing, bulk CSV import, and cohort promotion at year end. Guardians never self-register: the office creates the record from details it already holds and the parent activates it by proving control of that email or phone.

Staff & HR — directory, qualifications, documents, staff attendance, salary structures and payroll. A payslip is a frozen document: generating one copies the numbers, so next month's raise never rewrites last month's slip.

Attendance — daily and per-period registers. Marking a student absent on the day register notifies their guardians; a per-period absence does not, because that is a lesson matter rather than a safeguarding one.

Fees — fee heads, per-class structures, concessions, invoice generation, counter collection and online payment from the parent app through whichever gateway the school has connected. Payments are a ledger; the invoice's paid amount and status are always recomputed from it.

Examinations — exams, per-subject papers, marks entry, a grade scale, computed report cards with class rank, and a deliberate publish step.

Homework — assignments per section, submissions from the parent or student app, grading with feedback.

Communication — circulars with audience targeting (whole school, parents, a class, a section), leave requests, and a per-recipient notification feed that the apps read.

Facilities (optional) — library catalogue and loans, transport routes and vehicles, hostel rooms, and inventory.

Reports — nine canned reports with CSV export, all rendered by one self-describing screen.

The parent app

The home screen is a single chronological feed: announcements, attendance exceptions, homework set and graded, exam schedules, published results, invoices and receipts, leave decisions and calendar entries, newest first. Each card names the screen it opens, so the app routes on the payload rather than re-deriving where each type belongs.

Attendance only appears when it is an exception. A card saying a child was present every single day is a feed parents stop reading.

Fees are paid through whichever payment add-on the school has connected — the app asks what is available, shows those options, and settles through the gateway's own flow. A school with nothing connected shows "pay at the office", which is the honest answer rather than a button that cannot work.

The teacher app

Built around what a teacher does on arrival: today's lessons, which registers are still outstanding, homework awaiting grading, and pending leave requests for their class — in one call.

Taking a register is two taps: send a roll-wide default of present and list only the exceptions. A class of forty with two absences is one small request, not forty objects.

What SkoolyHub is not

• Not multi-school. One deployment, one school, by design.
• Not a learning-management system. Homework and marks are here; course content, video lessons and quizzes are not.
• Not an accounting package. Fees and payroll are tracked and receipted; there is no general ledger or tax filing.