Product
Multi-tenant school management platform
One deployment serving many schools and businesses, each seeing only its own people and records. The permission model is the part worth explaining, because it is the part that has to hold.
Status: In active development.
The problem
A school runs on relationships: which student is in which group, which teacher teaches which subject to which group, which parent is attached to which child. Those relationships change every term, and they are usually held in a spreadsheet that one person maintains.
Software for this is easy to build badly. The trap is a single database that quietly lets one school read another's data, which is discovered exactly once and never forgiven.
How it works
The platform is multi-tenant. Every record carries the organisation it belongs to, held as a business identifier, and every API operation verifies that the caller belongs to that organisation before it returns or writes anything. A query that cannot name its organisation does not run.
On top of that sit the entities the day actually needs: schools and businesses, classes, class groups, students, parents, teachers, subjects, the assignment of teachers to subjects, and the assignment of subjects to class groups.
What the API covers
The listings are paginated, because a school with two thousand parents should not be a single response.
- Paginated listings of parents, teachers and students
- Class and class-group management
- Assignment of subjects to classes and to class groups
- Assignment of teachers to subjects, including several teachers on one subject
- The inverse queries: classes not yet assigned to a subject, teachers not yet assigned to a subject
Why the inverse queries matter
The question an administrator asks in September is not "who teaches this subject". It is "which subjects still have nobody". A platform that answers only the positive question sends its users back to a spreadsheet to work out the gaps, so the inverse queries are first-class endpoints rather than a report bolted on later.
Four roles across the top, a permission check in the middle, and two separate organisation data stores below, showing that every role reaches data only through the check.
Architecture
Tenancy in the access path
The organisation identifier is part of how a record is reached rather than a column filtered afterwards. Adding a school is a row; it is not a deployment.
Permission checks at the API boundary
Every operation verifies the caller's organisation and role before touching data. The interface reflects that state; it never decides it.
Negative tests first
The tests that matter assert what happens when a record belongs to another organisation. A leak fails the build rather than reaching a user.
Technologies
PHP Laravel MySQL Redis React Next.js Docker
Services this uses
SaaS and custom software
Multi-tenant business platforms with per-organisation data isolation, roles and an API shared by every client.
Web applications
React and Next.js front ends against Laravel and Node APIs, including admin panels and RTL interfaces.
Start a project
Write in English, French, Romanian or Arabic. Every message gets a written answer within one business day.
Tell us what you are building.
Write in English, French, Romanian or Arabic. Every message gets a written answer within one business day.