Project 3 · School SaaS
The real school software. Multi-branch, multi-persona, with student enrolment, attendance, exams, payments, and circulars. The capstone project that uses every concept from the program.
This is the capstone. Everything you've learned, on one project.
By the end of Project 3 you will have a real, working, deployable school management system. Branch admins create students. Teachers mark attendance. Parents see their child's marks. The accountant tracks fees. Circulars go out by email. Razorpay payments arrive. And every byte of data is correctly isolated to the right branch and the right person — enforced at the database level by Row Level Security.
This is what software engineers do for a living. After Project 3, you have done it once.
Why This Project
A static website (Project 2) is a brochure. It tells the world what a school is. It changes once a quarter. It costs almost nothing to host.
A school system is the thing the school runs on. It changes every day. Hundreds of people use it. If it breaks, attendance can't be taken, fees can't be paid, parents can't see results. The cost of getting it wrong is real.
You will build that system from scratch. Not a watered-down version. A real one.
Why a school specifically? Because every concept in this training has been quietly building toward it. The school glossary in Phase 1. The spreadsheet-to-database walkthrough. The RLS Shield playground (branch-scoped policies). The Supabase tools (multi-tenant patterns). The Razorpay payment-flow playground. The SMS notifications module. All of it lands here.
You will not be learning new concepts in Project 3. You will be applying the concepts you already know.
Why now? Because by this point you have:
- A working stack (from Project 2).
- A school you understand intimately (Projects 1 and 2).
- Real comfort with React, Supabase, Claude Code, and your tools.
The expensive setup work is done. Project 3 is where it pays back.
What You Will Build
A multi-branch, multi-persona school management system. The features:
| Module | What it does |
|---|---|
| Students | Enrol new students. Manage profiles. Assign to a branch + grade + section. |
| Attendance | Teachers mark daily attendance per section. Parents see history. Admins see analytics. |
| Exams & Marks | Schedule exams. Enter marks per subject. Generate report cards. |
| Payments | Track fee schedules. Parents pay via Razorpay. Receipts emailed. |
| Circulars | Admin sends announcements to one branch / one grade / all parents. Email + (optional) WhatsApp. |
| Branches | Multi-tenant: each branch has its own data. Super admin sees everything; branch admin sees only their branch. |
And four personas, with very different views of the same data:
| Persona | What they see |
|---|---|
| Super Admin | Everything across all branches. The school's owner / principal. |
| Branch Admin | All data for their assigned branch only. |
| Teacher | Their assigned class(es) — attendance, marks. |
| Parent | Their child's data only. Attendance, marks, fees, circulars. |
| (Optional) Student | A read-only view of their own data. |
Five personas × multi-branch isolation × every module = a serious permissions matrix. We design it explicitly, enforce it in RLS, and test it.
The Stack
Same as Project 2 plus the parts you held back. Nothing exotic.
| Framework | Next.js 15 (App Router) — your Project 2 codebase, extended |
| Auth | Supabase Auth (email/password to start) |
| Database | Supabase Postgres |
| Multi-tenancy | Row Level Security policies — never UI-level guards |
| State (server) | TanStack Query (React Query) |
| State (client) | Zustand (for the auth user, branch context) |
| Forms | React Hook Form + Zod |
| Payments | Razorpay (Indian rupees, GST-aware) |
| Resend (transactional — receipts, circulars) | |
| SMS (optional) | MSG91 (DLT-registered templates) |
| Storage | Supabase Storage (student photos, exam papers) |
| Deploy | Vercel (same setup as Project 2) |
| Errors | Sentry (you'll set this up — production code without error monitoring is a bad idea) |
If a tool is new to you, the tools/ section has a guide for it. You will read those guides as you need them, not before.
How Long This Should Take
Plan for 6 weeks working 10-15 hours a week, or about 60-80 hours total.
| Phase | Hours | What you build |
|---|---|---|
| Architecture & Auth | 8h | Database schema, RLS, login screens for each persona |
| Module: Students | 10h | Enrolment form, list, search, profile pages |
| Module: Attendance | 8h | Daily mark-attendance UI, per-section, history |
| Module: Exams | 10h | Exam scheduling, marks entry, report card generation |
| Module: Payments | 12h | Fee plans, Razorpay integration, receipts |
| Module: Circulars | 6h | Admin compose UI, recipient targeting, email delivery |
| Module: Branches | 4h | Branch CRUD, super-admin switcher, RLS verification |
| Launch | 6h | Sentry, error states, edge cases, deploy, real users |
You can do it faster with Claude Code as a serious pair, slower if you want to deeply understand each piece. Either way is fine.
Method: Build One Vertical at a Time
The biggest mistake in a project this size is building everything at half-finished depth — half-done database, half-done UI, half-done auth, half-done payments. Then nothing works end-to-end.
The method that works: pick one user journey. Build it all the way through. Then pick the next.
The recommended order:
- Auth + super admin sees an empty database. Smallest possible vertical. No real data yet.
- Super admin creates a branch. First real data. First RLS policy.
- Super admin creates a branch admin. First multi-persona test.
- Branch admin logs in, sees only their branch. Verify RLS works.
- Branch admin enrols a student. First domain entity.
- Branch admin marks attendance for that student. First operational flow.
- Parent logs in, sees their child's attendance. First parent persona.
- Add exams. Marks, report card.
- Add payments. Real Razorpay test transactions.
- Add circulars. Email out.
Every step is end-to-end working before moving to the next. At any point, if Sahinov asked you to demo, you could.
What You Will Not Build
To stay focused, the following are explicitly out of scope:
- Mobile app — web only. (You can install the web app as a PWA on phones if you want — but no native app.)
- Public website features — that's Project 2. The school SaaS is internal only; the public site links to it (e.g. "Parent login" → SaaS).
- Library, transport, hostel, cafeteria modules — they're real school modules but each is its own project's worth of work.
- Online classes / video — out of scope.
- Internationalization — English only.
- A mobile-first design — desktop-first is fine for admin / teacher screens. Parent views should work well on phones.
You can add any of these later. They're not necessary to call the project complete.
Before You Start
You should have done all of:
- Project 2 finished. Static school site live with working contact form.
- You know the difference between a Server Component and a Client Component.
- You can read a TypeScript error and act on it.
- You have Supabase, Vercel, Resend, Razorpay accounts. (Razorpay can be on test mode.)
- You've done the RLS Shield playground and feel the model.
If any of those are unsure, go back and tighten before starting. This project gets hard if the foundation is shaky.
Ready
The next page (architecture.mdx) lays out the database schema and the RLS strategy before you write any code. This is the single most important page in Project 3. Don't skip it. A school SaaS without designed RLS is a security incident waiting to happen.