Reportcards ERP
A whole learning centre run from static HTML and one database.
The problem
Reportcards was run out of notebooks and WhatsApp. Attendance, fees, exam marks and the report cards the business is literally named after all lived in places that could not be queried, shared with a parent, or handed to a new teacher. It started as one English enrichment course students would actually work through; the register and the ledger were the parts that kept slipping.
What it does
The school ERP behind Reportcards — A Learning Centre: attendance, fees, exam scores, printable report cards, timetable, materials, class diary, bulletin and admissions, for students, parents and teachers. It began as Odyssey, a single English-enrichment course, which now sits inside it as one course among others.
Deliberately unglamorous where it counts: fees are a manual ledger with no payment gateway, and report cards print through the browser. Neither needs a paid service.
Why it is built this way
Static HTML talking straight to Supabase — no build step, no bundler, no server of our own. Both roles land on the same app and the signed-in profile decides what they see: attendance, fees, materials, exams and printable report cards, a timetable, a bulletin, plus teacher-only analytics, admissions enquiries, staff invites and a private vault. The original Odyssey voyage — Homer as ten islands, each gated behind comprehension questions — is now one course inside it. Installable as a PWA and wrapped as an Android app, so a student with a phone and a patchy connection is still covered.
What was hard
Two things. First, the access model, because it now holds children’s attendance, fee and progress records: every table is Row Level Security–gated, students reach only their own rows, teachers are recognised through a security-definer function, and role changes are impossible through the update policy by design — so the teacher portal is not the security boundary, the database is. Second, three HTML files have to move in lockstep: index.html is the source of truth, app-shell.html is a byte-identical copy the service worker caches, and the teacher portal is regenerated from index.html rather than hand-edited. Editing one and not the others is the fastest way to ship a stale shell to production, and it happened once already.
Outcomes
- 12 modules, one app
- Live at reportcards.in
- No build step, no server