ScholaBook is a school management product I built. The public case study covers context and technical shape; this article is about the product decisions that kept surfacing underneath the code.
I am not claiming a growth story here. I am describing judgement calls that show up whenever software has to serve institutions with roles, routines, and accountability—not just individual users clicking through a happy path.
The customer is a system, not a persona
Schools are not “a user.” They are overlapping roles—admins, teachers, parents, students—with different permissions, cadences, and definitions of success. A feature that delights one role can create operational load for another.
Product decisions got clearer when I stopped asking “is this useful?” in the abstract and started asking “whose daily workflow does this change, and who inherits the cleanup work?”
Tenancy is a product decision wearing infrastructure clothes
Multi-tenant SaaS forces early answers: what is shared, what is isolated, and what must never leak across organisations. Those answers shape data models, auth, reporting, and support tooling.
Opinion: if tenancy is treated as a late infrastructure detail, the product will eventually rewrite itself under pressure. Better to make isolation rules explicit while the domain model is still flexible.
Admin reality beats demo reality
School operations include imports, corrections, bulk actions, and messy historical data. If the product only works when data is clean, it works in demos.
I learned to prioritise boring admin leverage: clear permissions, recoverable mistakes, and workflows that match how staff actually update records during a busy week.