Loading...
← All work
Case study · CampusDelivered
One system for a whole school group, with every school kept separate.
A multi-school management system. Attendance, fees, exams, timetables, leave, salaries and announcements run for many campuses from one platform, with every role scoped to the right school.
- Sector
- Education
- Our role
- Multi-tenant architecture, typed API, web and parent apps
- Capabilities
- Platforms · Mobile
- Status
- Delivered
The challenge
School groups were running on spreadsheets and phone calls.
School groups run each campus on spreadsheets and phone calls, so nobody sees the whole picture and parents hear about fees and results last. Campus gives each school its own space and the group a single view.
What made it hard
- 01
Tenant isolation
Each campus must be fully isolated, while the group still needs a consolidated view across all of them.
- 02
Permission complexity
Super-admins, principals, teachers and parents each need different data, scoped to the right school.
- 03
Sensitive operations
Fees, payroll and exam results are high-stakes, and errors are visible to parents.
The approach
Multi-tenant by design, with isolation enforced on the server.
Every request carries its school context and is authorised server-side, so one tenant can never read another’s data. A modular NestJS API with validated inputs and a typed Prisma schema keeps a large domain manageable, and RBAC is designed per role rather than bolted onto a single admin.
System map
- AI step
- Person in the loop
- Service or store
How it works
- 01
Set up
A super-admin creates schools, then principals add classes, sections, subjects and staff, or import them from CSV.
- 02
Run the day
Teachers mark student attendance, staff attendance is logged, and timetable clashes are flagged.
- 03
Collect
Fee vouchers are issued and tracked, expenses and salaries are recorded against the same school.
- 04
Assess
Exams are scheduled, papers uploaded and results published.
- 05
Tell parents
Parents see attendance, dues, results and announcements for their own child.
Key decisions
How it stays simple at scale.
Decision 01
School context everywhere
Every request carries the school it belongs to, enforced on the server, so one campus can never read another’s data.
Decision 02
Five roles, not one admin
Permissions are designed per role, which keeps screens simple for teachers and parents.
Decision 03
Typed end to end
A modular API with validated inputs and a typed schema keeps a large domain manageable.
What shipped
An operating system for a school group.
Tenant onboarding
Schools, classes, sections, subjects and staff, created or bulk-imported from CSV.
Attendance and timetabling
Student and staff attendance, with timetable clash detection.
Fees and payroll
Fee vouchers, expenses and salaries ledgered per school.
Exams and results
Scheduling, paper uploads and controlled result publishing.
Parent app
Attendance, dues, results and announcements, scoped to their own child.
Architecture
A cross-section of the system.
Every layer, from what people touch down to where it runs, and the one job each layer does.
L1Interface
React
Role-shaped dashboards for admins, principals, teachers and parents.
L2Services
NestJS+TypeScript
Modular API with validated inputs and server-side tenant checks.
L3Data
Prisma+PostgreSQL
Typed schema with every record scoped to its school.
L4Platform
Firebase
Supporting platform services for the apps.
Our scope
Multi-tenant architecture/RBAC design/API design/Web application/Parent app
Where it is now
Delivered, with room for every new campus.
Campus is delivered as a multi-tenant platform. A new school is provisioned from the super-admin console, and the typed API keeps a large domain manageable as it grows.
Something like this in mind?
Tell us the problem. We will tell you honestly if we are the right team to solve it.