One codebase, two editions: building EduSpace for schools and universities
Schools and universities look similar from the outside and are not. EduSpace ships as two editions from a single codebase, and the interesting decisions were all about what to share and what to fork.
EduSpace is a pair of applications, one for students and one for teaching staff. It ships in two editions: a schools build and a universities build. Both come out of the same codebase.
That sounds like a technical decision. It was really a commercial one. A universities buyer looking at a product built around year groups, homework and GCSE subjects does not see a flexible platform, they see a schools product with the labels changed. The vocabulary is the proposition.
What actually differs between the two
Almost none of the plumbing. Authentication, roles, notifications, the design system, the dashboard components, the API: all shared. What differs is the domain model on top:
- Schools think in year groups, classes, homework and terms. Universities think in cohorts, modules, coursework and levels
- Grading differs entirely: GCSE grades against degree classifications
- Progression means moving up a year in one and accumulating credit in the other
- The reporting a head of department wants is not what a programme leader wants
Where we drew the line
The rule we settled on: share anything that is about software, fork anything that is about education. A date picker is software. A term is education. Once you have that line, most arguments about whether something should be configurable answer themselves.
Configuration is not free. Every toggle you add is a combination somebody has to test and a question a salesperson has to answer. Two clear editions beat one product with forty switches.
The feature that came out of the process
Building the university edition surfaced a genuine gap: work marked on method rather than on the final answer. Engineering and mathematics coursework is largely about the working, and typing it is painful. So the student application gained a handwriting surface, and that turned out to be worth more than the edition that prompted it.
That is the argument for building two editions rather than one generic product. Serving a specific audience properly tends to produce features a general one never would.
If you are weighing a multi-tenant product against separate builds, the honest answer is that it depends on whether your users share a vocabulary. If they do not, one product will disappoint both.