Why Akadesk is six products and not one
A primary school has no subject combinations and a polytechnic has no class teacher. Here is why we stopped trying to fit them into one schema.
Every school management system starts the same way: someone notices that a primary school and a secondary school both have students, classes and results, and concludes that one system can serve both. It can, for about six months.
Where the abstraction breaks
The break is not in the shared nouns; it is in the structure around them. A secondary school student belongs to an arm and carries a subject combination. A primary pupil belongs to a class and takes whatever that class takes. A tertiary student registers courses against prerequisite rules and a credit ceiling, and can carry a failed course forward for years.
Model all three in one schema and every screen grows a conditional. The registration form asks a primary school about credit loads. The report card template has a branch for subject combinations that most tenants never take. Six months in, the system is worse for all three institutions than three narrower systems would have been for each.
What we share instead
The products share a spine rather than a schema: what a learner is, what a term is, what an assessment and a result and a payment are. That is enough for an institution adopting a second product to recognise the first, and little enough that neither product distorts to accommodate the other.
- One Postgres database per product, never shared
- One tenant per institution inside that database
- The same four application surfaces in every product
- One design system, so the suite still looks like one thing