Mayowa

ayowa

All projects
School Management SaaSQ2 2025

EduGrade

A multi-tenant school platform for managing students, classes, scores, grading, and printable report cards.

Category
SaaS Platform
Timeline
Q2 2025
Stack
Next.jsTypeScriptFirebaseTailwind CSSshadcn/ui+3 more
Overview — read the full write-up

EduGrade helps schools manage academic records, configure their own grading systems, and generate report cards from a single platform. Parents can access their child's results through a school-specific portal, while each school's data remains isolated within the shared application.

EduGrade preview
Screenshots

The product in action

Screenshot 1 of 9

EduGrade screenshot 1
Case study

The story in three parts

01 — The Challenge

One Platform, Different School Rules

Schools don't all calculate results the same way. Assessment weights, grading scales, subjects, and academic structures can differ from one school to another. EduGrade needed to support multiple schools from a single application while keeping their academic data isolated and allowing each school to define how its own results are calculated.
Read more

02 — The Strategy

Multi-Tenancy Built Around Configuration

Each school's data is organized under its own Firestore namespace, keeping students, scores, classes, and grading settings separated while allowing one application to serve every tenant. Grading rules are stored as configuration rather than hardcoded logic, so schools can define their own assessment weights and grade bands without requiring code changes. Firebase handles authentication and realtime data, while Cloudinary and Nodemailer handle media and email.
Read more

03 — The Impact

A Complete Digital Results Workflow

EduGrade delivers the complete workflow from school registration and academic record management to weighted score calculation and printable report cards. Parents can access results through school-specific portals, while administrators manage students, teachers, classes, subjects, and grading rules from one dashboard. The project demonstrates a reusable multi-tenant architecture rather than a system built around a single school's assumptions.
Read more
Architecture

System Architecture

One Application, Isolated School Data

A single Next.js application serves school administrators and parents while Firestore namespaces each school's academic data and managed services handle authentication, media, and email.

Tenant-Isolated Data

Each school's students, scores, classes, and configuration live under its own Firestore namespace. This allows a single deployment to serve multiple schools while keeping their academic records separated.

Configurable Grading

Assessment weights and grade bands are stored per school instead of being embedded in application logic. The same grading engine can therefore handle different academic conventions without changes to the codebase.

Realtime Administration

Firestore realtime listeners keep academic records and configuration changes synchronized with the administrator dashboard. Subscription cleanup was handled explicitly to prevent listeners from accumulating as users moved between views.

Managed Supporting Services

Firebase provides authentication and database infrastructure, while Cloudinary handles uploaded images and Nodemailer supports transactional email. This keeps infrastructure focused on the application's core academic workflows.

Takeaways

Lessons & trade-offs

Every Query Must Respect the Tenant

Building a multi-tenant system made data boundaries one of the most important architectural concerns. A query outside the tenant namespace could break the isolation model, reinforcing the need to make the school context explicit throughout the data-access layer.

Tenant isolation

Make Variable Rules Configuration

Grading requirements vary between schools, so embedding those rules directly in the code would make the system difficult to reuse. Moving assessment weights and grade bands into school-level configuration made the application adaptable without additional deployments.

Configuration over hardcoding

Realtime Features Need Cleanup

Realtime Firestore subscriptions introduced listener-management concerns during development. Binding subscriptions properly to the component lifecycle prevented unnecessary listeners from remaining active after users left a view.

Subscription lifecycle

Start a project

Want something like this built?

EduGrade is one example of how I work — from architecture to shipped product. If you have a problem that needs this kind of thinking, let’s talk.