EduSuite

Low- and mid-tier schools can't justify per-seat SaaS pricing, and they certainly can't run a database per school. EduSuite answers that with a single multi-tenant platform where every school operates in its own logical space while sharing one codebase and one database.

The whole system — admissions, students, staff and academics — shipped across all five planned phases and runs in production. The interesting engineering isn't any one module; it's the guarantee underneath all of them: one school can never see another school's rows.

The multi-tenancy model

A database-per-tenant design is operationally hopeless for hundreds of small schools — backups, migrations and connection pools multiply until they crush you. EduSuite uses a shared schema where every tenant-owned row carries a tenant key, and Postgres row-level security policies filter every read and write by the authenticated tenant.

The consequence is that isolation is a property of the database, not a discipline the application has to remember. A future feature can forget to add a WHERE clause; it cannot forget the RLS policy, because the database enforces it on every statement.

The four domains

EduSuite covers the operational spine of a school:

• Admissions — applicant intake, screening and enrolment.
• Students — records, sections, guardianship, status.
• Staff — teachers and administrators, roles and assignments.
• Academics — classes, subjects and the academic calendar.

Deployment

The frontend is a React/Vite single-page app built in CI and served from Netlify's CDN; Supabase provides the Postgres database and authentication. It's a deliberately boring, cheap-to-run stack — the right choice for a product whose customers are price-sensitive schools.