An entire school operation, from enquiry to fee receipt, in one portal

What was the problem?

A growing preschool group was running academics, fees, attendance, admissions and parent communication across separate registers, spreadsheets and messaging groups. Nothing reconciled against anything else, so every parent question became a search and every fee cycle became manual arithmetic. Adding a second campus would have multiplied the problem rather than the workload.

What made it hard

What we built

A full-stack school management portal built from the ground up: multi-tenant architecture, role-based access for superadmin, admin, teacher and parent, automated fee generation and collection, attendance, daily activities, the admission pipeline, expenses, inventory, events and notifications.

What it does

• Admissions funnel

  Enquiry capture with source attribution through to enrolled student record.

• Versioned fee structures

  Immutable fee versions bound to students at enrolment, with add-ons and concessions.

• Fee generation and collection

  Monthly and annual generation, line-item payments, part-payments and PDF receipts.

• Attendance and daily activity logs

  Attendance marking plus meals, naps, mood and learning logs.

• Unified student timeline

  Attendance, activities, fees and events merged into one feed with per-viewer redaction.

• Role-based experiences

  Superadmin, admin, teacher and parent views plus custom roles, driven by server-issued permissions.

• Year-end promotion

  Dry-run preview then transactional cohort commit with rollback.

• Notification composer

  Role, branch and student targeting with branded HTML email delivery.

• Analytics dashboards

  Enrolment, attendance, fees, expenses and enquiry dashboards with CSV and PDF export.

• Bulk Excel import

  28-column template, 500-row cap, atomic all-or-nothing commit.

• Receipt and document sharing

  Delivered over both email and SMS.

• Inventory and expenses

  Operational record-keeping alongside the academic data.

• PWA parent portal

  Installable, with a conservative service worker that never caches authenticated data.

Engineering decisions

Choices that could have gone another way, and what each one bought.

1. 1

   Fee structures are versions, not rows

   A fee structure is an immutable version. A student is bound to the version active at their enrolment, and generation resolves class version → optional add-ons → student concessions → line items → obligation records inside a single transaction with idempotent upserts.

   Why it matters. Changing next year's fees can never silently rewrite last year's invoices, and a retried 'Generate fees' run cannot double-bill 300 students.

2. 2

   Four gates, and a deny list no admin can override

   Every request passes JWT auth, a role gate, a permission gate and a tenant scope gate. Above that sits a school-configurable teacher allowance system; beneath it, a hard-deny list. Teacher responses are field-masked server-side and class access is verified per record.

   Why it matters. A school can tune its own roles without being able to misconfigure its way into exposing fees or analytics to teachers — and a teacher physically cannot read another class's data through the API.

3. 3

   Academic-year scoping as a first-class concept

   A dedicated scope resolver translates every query into the correct academic-year window: period keys, month ranges, timezone-correct school dates, and SQL fragments deciding which fees belong to which year.

   Why it matters. This is the layer most school systems get wrong, and getting it wrong produces balances and reports that are quietly incorrect across year boundaries.

4. 4

   Year-end promotion is preview-then-commit

   A dry run shows exactly which students promote, graduate or are held back. The commit then rolls the entire cohort forward, archives enrolments and re-binds fee versions transactionally, with rollback on any failure.

   Why it matters. The riskiest annual operation in a school system becomes something you can check before you do, and something that cannot end up half-done.

5. 5

   Asynchronous dispatch without pretending to be a queue

   Publishing a notification returns 201 immediately; recipient resolution and fan-out happen off the request path, with per-recipient failure isolation so one bad mailbox cannot abort a broadcast. Heavy jobs use transactional batches with ON CONFLICT DO NOTHING rather than a job queue.

   Why it matters. An admin messaging 400 parents never waits on SMTP. This is deliberately described as a non-blocking dispatch layer rather than a queue, because that is what it is — the natural upgrade to QStash or BullMQ would buy retries, dead-letter handling and scheduled sends.

Technical detail

Collapsed by default. Open whichever part you are evaluating.

Before and after

The build, by the numbers

What was built, at what scale. These describe the system's size, not its business results.

REST endpoints

154REST endpointsAcross 26 route modules

database tables

30database tablesWith 38 versioned migrations and a schema_migrations ledger

automated tests

764automated tests705 backend and 59 frontend

domain services

38domain servicesRoughly 11.8k lines of backend service layer

role-based experiences

4role-based experiencesSuperadmin, admin, teacher and parent, plus custom roles, on one codebase

validator modules

20validator modulesZod schema validation on every mutating endpoint

What changed as a result?

End-to-end school operations automated in one platform, with a single source of truth for academics, finance, staff and parent communication.

• Multi-tenant, so additional campuses are configuration rather than a rebuild
• Four distinct permission levels, so parents and staff see only what applies to them
• Fee generation and collection automated across terms

Why does this matter in SaaS & startups?

Most first builds are too large. The useful MVP is the smallest thing that tests whichever assumption would sink the business if it were wrong. Both of our internal SaaS builds — a multi-tenant school portal and a restaurant POS — started as the narrow system one operator needed, then earned their scope.

• Scope that assumes the idea is already validated

  Settings screens, admin tooling and dashboards feel like progress and prove nothing. Building them before anyone has paid is the most common way a runway disappears.

• Multi-tenancy retrofitted too late

  Serving a second customer from a system built for one is an expensive rewrite. Where multiple organisations are clearly coming, tenancy belongs in the first architecture.

• No route to a real user

  A product that exists only on a laptop cannot be tested. Deployment, accounts and access need to work from the first week, not the last.

• Handover that leaves you dependent

  Code you cannot access, hosting in someone else's account and no documentation turn your own product into a negotiation. Ownership from day one avoids that entirely.

More on what we build for SaaS & startups →

See it running