Summary

Multi-tenant SaaS architecture rests on a premise that has held for decades: that the most expensive part of delivering software to many customers is writing the code. Every structural decision follows from it. Write once, share as many layers as possible, express customer difference as configuration, fall back to custom code only when configuration runs out. Because the resulting flexibility is fixed when the product is designed, requests outside it tend to be met under deadline with special cases in shared code, and technical debt accumulates.

This paper takes as its working assumption that the premise no longer holds, and follows the consequences. The question that organises the argument is what the product's core value is, stated in terms of the needs of its domain. The answer decides what stays shared, what can move, and how the product can be priced. When producing code becomes cheap, the layer at which a product draws its line between shared and per-customer can move down. Pressure to move it is arriving from three directions at once. Customers want to start using the product without a long onboarding. They want changes to be easy after go-live. They want it personalised below the tenant, down to the individual user, and they increasingly expect their own agents to operate it.

Moving that line is a deep architectural change, and depth is where the risk sits. This paper argues for a specific order of work. Greenfield products move the line from the bottom, because there is nothing to break. Existing products move it from the top, because the top two layers, customer onboarding and the user interface, can be rebuilt without touching the domain logic the revenue depends on.

The mechanism for rebuilding those layers at useful speed is a second layer of governance above the product's knowledge graph, in the form of a formal grammar. The knowledge graph records what does not vary between customers, which makes it the right starting inventory, at a level above the detail that generating anything needs. A grammar adds the rules a schema cannot express, gives an agent a target with far fewer degrees of freedom than a general-purpose language, and reduces per-attribute human review by moving most checks into functional tests the agent can run itself. Section 9.1 sets out exactly what that does and does not guarantee.