1. The premise that has been withdrawn

A SaaS product is a bet about where cost concentrates. The bet that shaped current architecture was made when engineers were the scarce resource and a line of code written once and sold a thousand times was the whole economic idea.

That bet produced a consistent set of structural rules.

Rule	What it optimised for
Write the code once	Engineering cost amortised across the customer base
Share every layer that can be shared	Infrastructure, database and support cost
Express customer difference as configuration	Avoiding a code change per customer
Write custom code only where configuration runs out	Containing the long-term maintenance surface

Each rule is sound given the premise, and the standard descriptions of mature SaaS architecture state them directly. Microsoft's SaaS maturity model places the most mature products at a single instance serving every customer, "with configurable metadata providing a unique user experience and feature set for each one" (Architecture Strategies for Catching the Long Tail, Chong and Carraro, Microsoft, 2006). Salesforce describes its platform in the same terms: a customer's customisation is stored as metadata, and the platform does not create a table or compile any code for it (The Salesforce Platform Multitenant Architecture, Salesforce, 2016).

Together the rules produce a product whose flexibility is fixed at design time, because the set of things configuration can vary, and the rules by which those things combine, are decided when the configuration mechanism is built.

1.1 Fixed flexibility and technical debt

Fixed flexibility has a cost that accumulates. When a customer asks for something the configuration mechanism did not anticipate, the request usually arrives with a deadline attached, and the quickest way to meet it is a special case: a customer-specific branch, a conditional in shared code, a copied module. Generalising the mechanism so that the next customer's variant becomes a configuration change would take longer, and the urgency of the current request wins. Each such decision is technical debt in the standard sense: "design or implementation constructs that are expedient in the short term, but set up a technical context that can make future changes more costly or impossible" (Managing Technical Debt in Software Engineering, Dagstuhl Seminar 16162, 2016).

The pattern is well documented. In the InsighTD family of industry surveys, 653 practitioners across six countries named time pressure or deadlines as the single most cited cause of technical debt (Ramač et al., Journal of Systems and Software, 2022). The closest direct evidence for the customer-driven case comes from software product lines, where each customer variant plays the role a tenant-specific extension plays in SaaS. A study of cloning across six industrial product lines recorded the mechanism in a practitioner's own words: "When a new customer came, we needed to decide how to implement his requirements in the fastest way. We do not have time to think thoroughly about generic approaches" (Dubinsky et al., CSMR 2013). A later field study of opportunistic reuse found time pressure to be the main reason teams did not consider alternatives to copying (Wolfart et al., Journal of Systems and Software, 2024).

The debt compounds because it sits in the shared layers. Developers in a longitudinal study reported losing on average 23% of their working time to technical debt, and being frequently forced to introduce more of it (Besker, Martini and Bosch, Journal of Systems and Software, 2019). In a multi-tenant product every special case added for one customer is carried by all of them, which is how a change made for one customer can surface as a defect for another.

1.2 What has changed, and three questions

The first generation of SaaS sold the removal of installation. Software arrived on tap rather than on a disc, and Salesforce's launch event was themed around "The End of Software" (The History of Salesforce, Salesforce, 2020). That value proposition eroded as running software in the cloud became cheap, so the proposition moved upward into configuration, integration and platforms. Salesforce itself followed with AppExchange as an integration marketplace and Force.com as a development platform (Cloud Computing and SaaS as New Computing Platforms, Cusumano, Communications of the ACM, 2010). The architecture underneath did not move with it. What runs at most B2B SaaS companies today is a delivery model designed around expensive code, carrying a value proposition that has been revised several times.

The evidence on how far the cost of producing code has actually fallen is mixed, which is why this paper treats the premise's withdrawal as a working assumption. Field experiments covering 4,867 developers at three companies found a 26% increase in completed tasks with an AI coding assistant (Cui et al., Management Science, 2026). A randomised trial with experienced open-source developers found tasks taking 19% longer with AI tools (METR, 2025), and METR's 2026 follow-up describes its own updated estimate as weak evidence (METR, 2026).

Vendors now report coding agents completing whole applications with little intervention. Anthropic describes 16 parallel agents producing a 100,000-line C compiler that builds Linux 6.9, over nearly 2,000 sessions, with people designing the tests and the environment (Building a C compiler with a team of parallel Claudes, Anthropic, February 2026). OpenAI describes Codex building a design tool from a blank repository over about 25 hours and 30,000 lines, which its author calls an experiment rather than a production rollout (Run long horizon tasks with Codex, OpenAI). These are vendor accounts of single projects rather than controlled measurements.

With the premise withdrawn, three questions follow.

Is the existing architecture worth continuing to maintain as it stands?
If a different architecture is coming, what distinguishes it from this one?
What is the product's core value proposition, stated in terms of the needs of the domain it serves?

Competitors will not wait, so the answer to the first is no. The second is the subject of this paper, and answering it depends on the third.

1.3 The value proposition, in domain terms

Under the old premise the value proposition could be stated in terms of delivery: the software is written, hosted, maintained and upgraded on the customer's behalf. Each revision since has stayed at that level, adding configuration, integration and APIs to what is delivered. None of these explains why a customer in a particular domain buys this product over another, and as producing code gets cheaper they converge across vendors. McKinsey's analysis of generative AI in software makes the same point: faster development "will mean competitors and upstarts can rapidly replicate offerings at a lower cost" (Navigating the generative AI disruption in software, McKinsey, 2024).

What stays distinctive is the product's encoded understanding of its domain. For a payroll product that is the knowledge of how pay is calculated across statutes, company policies and employee life events, and of how those rules change over time. For a dealer-management ERP it is how parts, warehouses, inventory and service relate for an equipment dealer. That domain capability is the product's strongest asset. It is where correctness is decided, and it is what the revenue depends on the product getting right. Bain's 2025 assessment of agentic AI and SaaS points the same way, naming proprietary data, domain-specific content and deep domain knowledge among the defences that hold (Will Agentic AI Disrupt SaaS?, Bain, 2025).

Stating the value proposition this way supplies the answers the rest of the paper depends on.

Question the paper returns to	How the domain value proposition answers it	Where
Which parts of the product every customer should share	The domain capability, because it is the asset and every customer depends on it being correct	Section 2
How a customer's variation should be accommodated without accumulating technical debt	As a composition of the shared domain capability, described for that customer and checked against the domain's rules, so that a new variant adds to that customer's own description and leaves the shared code unchanged. A need the shared capability cannot yet express is met locally for that customer, and generalised into the shared capability once its wider applicability is understood	Sections 2, 10 and 15
How the product should be priced	By the domain capabilities each customer's implementation actually uses, plus the work of assembling them for that customer, in place of a common bundle priced by a measure of overall use	Section 4
What the product should offer to whoever operates it, whether a person or software acting on their behalf	What the domain can be asked to do, rather than the screens that currently front it	Section 3
What the product's own record of its capabilities should hold	The domain capability, which is exactly what does not vary between customers	Section 8
How a customer's requirement should be stated so it can be checked before it takes effect	In the domain's own vocabulary and rules, at the level a domain expert states it	Sections 9 and 15

Everything above the domain capability, meaning the screens, the setup process and the per-customer mapping, is how that value is delivered to a particular customer. Those are the parts whose cost has fallen, and the parts that can reasonably vary from one customer to the next.

1. The premise that has been withdrawn

1.1 Fixed flexibility and technical debt

1.2 What has changed, and three questions

1.3 The value proposition, in domain terms

Sources