A product should not carry every client's exceptions.
When we began preparing LEVORA CMS as a commercial product, one of the most important decisions was not visual. It was defining where the Core ends and where a project begins.
The Core brings together the capabilities that need to exist consistently in every installation: authentication, users, Media, Studio, page management, system operations and the update engine. These areas must remain predictable because they form the foundation that will be installed repeatedly.
The website lives in another layer.
Design, pages, implementation-specific behaviour and project-specific rules do not belong in the base product. They live in the Project and, when necessary, in external modules. This allows a website to be deeply customised without turning the CMS into a collection of exceptions.
In practice, this separation reduces two forms of technical debt: changes for one client no longer contaminate future installations, and the Core can receive genuine fixes without carrying design decisions that do not belong there.
Modules for capabilities, Project for implementation.
Not everything should live on a Studio page. When a feature has its own data, permissions, routes or lifecycle, it makes sense to treat it as a module. Projects, for example, evolved in this way: content managed in the back office, dedicated public routes and portable transfer between installations.
The rule we follow is deliberately simple: the Core provides the infrastructure, the Project defines the website and modules add specific capabilities.
Stability does not mean standing still.
Separating layers is not about preventing evolution. It is about choosing the right place for each change. A system can continue to grow without repeatedly reopening the foundation that has already been validated.
It is less visible than a new interface, but this is precisely the kind of decision that determines whether a platform remains manageable once it stops being a prototype and starts being reused in production.