The tidy thing to do, commercially, would be to put everything behind one login. One brand, one price list, one place to send people. Every SaaS playbook says so. We keep not doing it, and it is worth explaining why.
The software that runs a school committee and the software that runs a sports club are, underneath, close to the same program. Members, meetings, money, minutes. If you are looking at the code, merging them is obvious. If you are the secretary of a P&C, it is not obvious at all — you do not want a flexible tool for organisations, you want the thing that already knows what a P&C is.
A tool that knows where it lives
This is what we mean by habitat. A product built for one habitat can use that habitat's words, assume its shape, and skip every question whose answer is already known. It does not have to ask which modules you want enabled. The defaults are simply right, because there is only one kind of user to be right for.
A general tool cannot do that. It has to ask, because it does not know. Every one of those questions is a small tax on the volunteer who did not ask to be treasurer, and those taxes compound into the thing everyone recognises: software that needs a training session before anyone can use it.
The catalogue grows sideways, not just up.
What this costs us
Plenty. Every product is a separate brand, a separate site, a separate support inbox, a separate thing to explain. Shared engines help with the code and not at all with any of that. We are choosing more work in exchange for tools that feel like they were made for one person in particular.
The trade we are refusing is the one where a product gets more capable and less usable at the same time. When a job here gets big enough to be its own thing, it leaves and becomes its own product, with its own name. That is the whole rule.