Launch
Sentry, edge cases, real users. The last 6 hours that turn a working project into one a school could actually use.
You have a feature-complete school SaaS on your laptop. Now you make it survive contact with real users. Plan ~6 hours.
1. Sentry Integration
Production code without error monitoring is a black box. The first thing you do is install Sentry.
Skim the Sentry tool guide for the full setup. The short version:
The wizard sets up everything — config files, source map upload, sample errors. After running, do a test:
Refresh, see the error caught, then check Sentry dashboard — your error should appear within seconds with a full stack trace.
Remove the test throw. Commit the rest.
2. The 12 Edge Cases You Must Handle
Real users will hit edge cases. Before launch, deliberately think through each:
| Edge case | What goes wrong if you don't handle |
|---|---|
| A teacher's only section is deleted | They log in to an empty home page with no useful action |
| A student is enrolled but has no section yet | Their parent can't see any attendance/marks |
| A parent registers but their child's enrolment is "pending" | They see a hopeful empty state, not a 404 |
| Two parents share custody | Currently we have one parent_id per student — decide your stance |
| A circular goes to a parent who has unsubscribed | Need an email_preferences table or a List-Unsubscribe header |
| Razorpay webhook arrives late | Parent sees "Payment pending" but actually it succeeded. Add a 5-min reconcile job |
| An exam is published before all marks are entered | Show clear "Marks pending for 3 subjects" state |
| An admin deletes a teacher | All their class_sections need reassignment, not orphaned |
| A school year ends | Move all Grade 5 students to Grade 6 in bulk. Add /admin/promotion flow |
| A duplicate enrolment attempt | Unique constraints catch it, but show a friendly message |
| A parent enters a wrong child's admission no | Validate against admission_no + parent_email match |
| A user's session expires mid-action | Catch the auth error, refresh the session, retry once |
You don't need to solve all 12 perfectly. You DO need to know how your system behaves in each. Make a list of which ones you handle now and which are documented as "known issues."
3. Production Environment Setup
The setup is identical to Project 2's .env.local but doubled. Production goes on Vercel; dev stays local.
Vercel project → Settings → Environment Variables. Add:
Mark each "Production" and "Preview" — not "Development" (those stay in .env.local).
Supabase secrets are separate (they live in Supabase, not Vercel):
Where supabase/.env has the edge function secrets (RESEND_API_KEY, RAZORPAY_*, etc.). Never commit this file — add to .gitignore.
Save every key to VaultMate with clear "Production" labels.
4. CSP and Security Headers
Update next.config.ts with the production CSP (the Project 2 base + a few additions for Razorpay):
Plus the standard headers from the global standards (X-Frame-Options, Strict-Transport-Security, etc.).
5. Set Up Monitoring Beyond Sentry
| Service | Purpose | Cost |
|---|---|---|
| Sentry | Error tracking | Free tier sufficient |
| UptimeRobot | Pings your site every 5 min, alerts if down | Free 50 monitors |
| Vercel Analytics | Real-user perf (LCP, CLS, INP) | Built-in |
| Supabase project advisor | Security + perf warnings | Built-in |
Set up UptimeRobot to ping:
https://your-school.vercel.app(the marketing site from Project 2)https://your-school.vercel.app/login(the SaaS login)https://yourproject.supabase.co/functions/v1/health(an edge function that returns 200 — add a tinyhealthfunction)
If any goes down, you get an email/SMS in under 10 minutes. Far better than finding out from a panicked parent.
6. Get One Real Person to Use It
Same pattern as Project 1 and 2. Pick one person who would actually find this useful — a teacher you know, the principal of a small school, your spouse if they teach. Don't pick 5 people. Pick 1.
Walk them through:
- Set them up as a
branch_adminin your fictional school. - Show them how to enrol a student, mark attendance, schedule an exam.
- Then leave them alone for 15 minutes. Let them poke.
- Come back and listen.
What they get wrong is what your real users will get wrong. What confuses them is what you need to fix.
Common feedback from this first session:
- "I can't find where to add a new class"
- "Why does it ask for date of birth when I want to add a teacher?"
- "How do I send a circular to just two parents?"
- "The fee dashboard is overwhelming"
Take notes. Don't fix anything that session. Decide afterwards what's worth changing in the next iteration.
7. Document What Exists
Create README.md at the project root with:
- One paragraph on what the system does
- Tech stack list
- How to run locally (the
pnpm devflow) - How to deploy (the
git push → Vercelflow) - The 12 tables and their relationships (link to the architecture page)
- The 5 personas and what they can do
- A "Known issues" section — the edge cases you didn't fully solve
If you ever hand this off to someone (or come back to it 6 months later) the README is what saves an hour.
8. The Final Deploy
Wait for Vercel + Supabase deploys to settle. Hit the production URL. Log in. Walk through one full flow as each persona. If it all works, you're done.
9. Reflect
You just built a real, production-grade SaaS over 6 weeks. Things to write down for yourself before you close the laptop:
- The single hardest bug you fixed and how you found it
- One pattern that you'll use on every future project
- One thing you'd architect differently if starting over
- One module you'd prioritise differently
- One thing you genuinely don't understand yet and want to learn next
These notes are the most valuable artefact from this project. The code will be obsolete in 3 years. Your reflection won't.
What's Next
The checklist confirms everything is done. After that, you have completed all three projects in the program — the curriculum is yours.