Schooly — a multi-tenant school platform, built by a former teacher.
Twelve years in a classroom turned into software for the people still in one. Shares a monorepo with KeyHQ.
§01The problem
Small schools run on registers, photocopies, and the one staff member who knows the timetable. Attendance is paper, fee receipts are a carbon book, and report cards are a spreadsheet that lives on a single laptop. Enterprise ERPs exist, but they are priced and shaped for institutions ten times the size.
The role model is genuinely complex: admins run the school, teachers own their classes, students see their own record, and parents see their child's. Each role is a different surface over the same tenant-isolated data — the exact problem KeyHQ already solved once.
§02System architecture
Schooly is the second app in the Turborepo. The biggest architectural win was not rebuilding multi-tenancy and auth from scratch — those graduated into shared packages the moment a second consumer existed.
§03Three decisions worth defending
Promote tenancy to a shared package
KeyHQ and Schooly both need “isolate every query by tenant.” Instead of copying the pattern, the row-scoping helpers and Drizzle middleware became shared/db. One place to audit, two apps that benefit.
Parents are first-class, not a sub-login
Most low-end school tools bolt parents onto the student account. Schooly gives parents their own role and their own minimal surface — attendance alerts and fee dues — because that is what actually drives adoption with families.
Report cards as data, not PDFs
Grades live as structured rows, and the printable report card is a render of that data. It keeps history queryable (term-over-term trends) instead of trapping it in a generated file nobody can search.
§04Hardest problems, plainly
Extracting shared packages without a big-bang refactor
Pulling auth and db out of KeyHQ into the monorepo, while KeyHQ was already deployed, meant moving code without changing its behaviour. The move was done in small, type-checked steps with the build as the safety net.
A fourth role doubles the guard matrix
KeyHQ had three roles; Schooly has four, and parent ↔ student ↔ class relationships are many-to-many. Modelling “a parent of a student in this class” cleanly took more schema thought than the rest of the app combined.
Designing for the non-technical front office
The real user is an administrator who has never used SaaS. Every flow had to survive the “would the school clerk get this in one try?” test — which is a different bar than building for developers.
“I spent twelve years explaining things to people with zero prior context. Building Schooly is the same job, only the audience is the school office instead of a classroom.”— Parm, on why this one is personal