ClassPulse moves a school program's grading off fragile spreadsheets

The problem

The Sitapatr Pratom English Program, a primary-school program, ran its grading on separate spreadsheets, one gradebook per subject, each with its own copy of the formulas. Teachers, the head teacher, the program director and the IT office all needed different parts of the same data, and the only safeguard against a broken formula was someone noticing. Reports to parents were assembled by hand. ClassPulse is the product I designed and built for that program. It keeps marks, evaluations, timetables and staff records in one place, shows each role only what it should see, and holds back any report until it is complete and correct.

Constraints

• The app contains real pupil records, so privacy and role limits came first, and the repository stays private.
• The grading had to match the school's existing formula exactly, so I had to recover it from the spreadsheets.
• Four roles with very different rights: teacher, head teacher, program director and IT.
• No backend yet. Data lives in the browser and syncs between open tabs while the server is planned.

What I did

Strategy

I mapped who does what before building screens. Teachers enter marks only for subjects on their timetable. The head teacher can correct any mark, but must give a reason, and the change is logged. The director runs contracts, attendance, leave and timetables and can read every grade but change none. IT manages pupil records and the school year and never sees a mark.

Engineering

• Grading recovered from the source. Python scripts read five gradebooks across 32 sheets and wrote the formula down in four layers. The audit found three weight sets that don't add to 100% (one term total came to 120%) and 39 places where a single pupil's formula had been edited differently from the class. The app now refuses to publish a scheme until every weight totals exactly 100%.
• Readiness locks. A grades report opens only when every subject is fully and correctly marked, and an evaluation report only when every subject teacher has marked theirs final. While locked, the screen lists exactly what is blocking it and who needs to act.
• Evaluations with rules. One evaluation per class, subject and pupil, moving from draft to final. Each pupil gets exactly four traits from a subject-specific set before it can be finalized.
• Parent reports as A4 PDFs or a share link that expires after seven days.
• Also built: homeroom boards, timetables with weekly teaching hours, leave requests, class cover, duty rosters and a monthly staff scorecard.

Design

A collapsible sidebar grouped by job, light and dark modes, charts parents can read, and a guided tour that explains each role's screens on first sign-in.

AI

A lesson-plan generator sends a teacher's brief and textbook photos to Claude, which must answer through a structured tool so the plan always arrives in the school's format, exportable to Excel or PDF. The key stays on the server, and the route accepts same-site requests only, with size and rate limits.

Outcome

• A working app at version 0.18 after 44 commits. The changelog marks 1.0 as the first release used with live school data, so it is not in production yet.
• Documentation includes 13 hands-on backend labs that run in the browser, all verified, and every one of the 101 front-end files commented.
• Effects on teachers' time or report accuracy have not been measured.

What I'd change next time

I'd build the real backend and sign-in earlier. Keeping data in the browser made fast iteration easy, but every rule I wrote for the front end will have to be enforced again on the server. I'd also run the spreadsheet audit on day one, since it shaped almost every rule that followed.