# SaaS Isn’t Dead. Sameness Is.

> Source: <https://aicoding.leaflet.pub/3mtu6c5wsvc2n>
> Published: 2026-08-24 20:45:12+00:00

Everyone suddenly wants to tell you SaaS is dead.

The Klarna-replaced-Salesforce story spread because it fit the mood, whatever the exact boundary between “replaced the CRM” and “consolidated the data underneath it” turned out to be. Agents are starting to do work that once required people clicking through applications. Seat-based pricing looks vulnerable when the seats themselves stop doing the work.

Even [Gartner now estimates](https://www.gartner.com/en/newsroom/press-releases/2026-07-01-gartner-says-us-dollars-234-billion-in-enterprise-application-software-spend-is-at-risk-from-agentic-artificial-intelligence) that as much as $234 billion in enterprise application spending could be exposed to what it calls “agentic arbitrage” by 2030, roughly 20 percent of enterprise SaaS spending.

But Gartner itself hedges the apocalypse. It calls what is coming less an apocalypse than a metamorphosis.

I think that’s right.

And I want to make a more specific prediction about what SaaS turns into.

Companies will still pay other companies to host important software, secure it, operate it, maintain authoritative data, track regulatory changes, connect to external networks, and answer the phone when something breaks.

What is much less obviously going to survive is the assumption that ten thousand different companies should use substantially the same application.

**The next SaaS company may run one service underneath ten thousand different applications.**

Suppose your company has an unusual sales process.

Twenty years ago you had two realistic options.

You could buy a CRM designed for thousands of companies and configure it until it approximately fit the way you worked.

Or you could build your own.

The second option sounded appealing until somebody calculated what “build your own” meant: developers, designers, product management, security, hosting, integrations, upgrades, migrations, support, on-call coverage, and years of maintenance.

You would spend millions building a worse version of something Salesforce already did, then own it forever.

Of course you bought Salesforce.

The same logic played out across the enterprise. Companies bought SAP, Workday, Jira, ServiceNow, Oracle, and hundreds of other products, then gradually changed themselves to fit the software.

A CRM has concepts for opportunities, stages, accounts, contacts, and forecasts. A project management system has issues, epics, sprints, statuses, and workflows. An HR system has its own model of employees, managers, organizations, approvals, and reviews.

These can be good abstractions. But they are still choices.

Over time, the choices made by software vendors become the language of the organizations using them.

We tend to describe this as standardization or best practice. Sometimes it is.

Sometimes it is simply the result of an economic bargain:

Adapting the organization to the software is cheaper than adapting the software to the organization.

For decades, that bargain was obviously correct.

The first copy of a serious software product was enormously expensive. The ten-thousandth copy cost almost nothing.

SaaS turned that asymmetry into one of the best business models ever invented.

SaaS did more than move applications into the browser.

It made sameness operationally valuable.

The vendor controlled the running system. Everyone could be upgraded. Security fixes rolled out centrally. Features shipped continuously. The vendor no longer had to support hundreds of customer installations that had been modified beyond recognition.

This produced one of enterprise software’s most durable maxims:

Configure, don’t customize.

Customization created forks.

The customer changed the software. Then the vendor changed the software. Somebody had to reconcile the two.

Repeat that for several years and the customer ended up stranded on an ancient release with a pile of modifications nobody fully understood.

Configuration solved that problem by constraining variation. The vendor decided in advance which dimensions could differ: fields, permissions, workflow states, plugins, integrations, feature flags.

Customers could be different, but only in ways the product had anticipated.

That was an excellent compromise.

But it was not a law of software engineering.

**“Configure, don’t customize” was a coping strategy for expensive code.**

If customer-specific software becomes cheap to produce and cheap to reproduce, that trade changes.

Imagine an internal approval process used by fifty people.

It is peculiar to one company because of two acquisitions, three jurisdictions, an old regulatory settlement, and a division of authority no sane product manager would ever design from scratch.

Today the company probably buys a generalized workflow platform and spends months configuring it.

Now imagine a small internal team can produce a purpose-built application in a few days.

The company’s identity system already exists. The necessary data is available through stable interfaces. Authorization rules are explicit. Hosting, observability, security, and deployment come from a shared platform.

The application does not need to appeal to five thousand other customers.

It does not need a roadmap.

It does not need a total addressable market.

It needs to solve this problem for these fifty people.

That changes what software is economically allowed to exist.

For most of software history, an application had to justify its production cost. Either enough people needed roughly the same thing, or the problem was important enough to justify bespoke development.

As production costs fall, the minimum viable market shrinks.

One organization. One department. Eventually, for some software, one person.

This leads to a strange possibility:

**More software may mean fewer software companies.**

An insurance company might generate twenty highly specific internal applications next year and never release any of them publicly. If three replace existing SaaS contracts, the world contains more software and less commercial software spend at the same time.

That is a very different dynamic from the software economy we grew up with.

“SaaS is dead” bundles together several different ideas.

The software is hosted by someone else. The vendor operates and secures it. The vendor maintains authoritative data, updates regulatory logic, handles migrations and integrations, and takes responsibility for availability and support. Customers pay for that capability over time.

And historically, thousands of customers have also used substantially the same application.

Cheap generation attacks that last property much harder than the others.

I don’t want to run my own payment network because an agent can generate a checkout page.

I don’t want to maintain tax tables because an agent can build payroll screens.

I don’t want every hospital generating its own authoritative interpretation of medical records.

A lot of the value in modern SaaS has surprisingly little to do with the visible application.

It is data, trust, networks, compliance, operational responsibility, domain knowledge, auditability, accumulated history, and someone being accountable when reality gets complicated.

AI can destroy the interface to a service while increasing demand for the service underneath it.

That is why the disappearance of seats or screens does not imply the disappearance of the vendor.

This matters for pricing too.

Traditional SaaS pricing often maps neatly onto humans using applications.

Per seat. Per user. Per agent.

That worked because the application was both the place where the work happened and the place where the vendor captured value.

Agents weaken that link.

A payroll provider does not become valueless because an employee stops opening its payroll interface. The customer is still paying it to calculate payroll correctly, keep up with tax law, move money, file with governments, maintain records, and accept operational responsibility.

So perhaps it increasingly gets paid for employees processed, money moved, filings completed, jurisdictions supported, or outcomes guaranteed.

A payments company already charges around transactions rather than seats. A data company can charge around information, rights, volume, or usage. A security company can charge around protected assets, workloads, identities, or risk.

A substrate company has to price the thing it actually supplies.

This will be painful for SaaS companies whose economics depend on selling access to screens that agents no longer need.

It may be excellent for companies whose real value was hidden behind those screens all along.

The easiest way to imagine the new model is to split the application into pace layers.

At the bottom are things we want to move slowly: identity and authority, authoritative data, audit history, core domain semantics, regulatory logic, security boundaries, external contracts, networks, money movement, and accumulated operational knowledge.

That last one matters more than it first appears.

[Gartner argues](https://www.gartner.com/en/newsroom/press-releases/2026-07-01-gartner-says-us-dollars-234-billion-in-enterprise-application-software-spend-is-at-risk-from-agentic-artificial-intelligence) that useful agentic systems will need to retain deep institutional memory and customer context over time. Every exception resolved, correction made, policy interpreted, and operational failure understood can become part of the durable capability underneath the application.

The screens may be disposable while the institution underneath them gets smarter.

Above those slow layers are things that can move much faster: workflows, interfaces, reports, approvals, automations, dashboards, local policy, orchestration, agent behavior, and team-specific tools.

Today’s SaaS product typically bundles both layers together and expresses customer differences through configuration.

A generative SaaS company can operate the slow layer and generate much of the fast layer separately for each customer.

The vendor can still host everything. Still secure it. Still monitor it. Still control deployment. Still provide support.

But customer A gets one application, customer B gets another, and customer C may interact mostly through agents.

**The software is bespoke. The service is shared.**

That is not the death of SaaS.

It is mass-customized SaaS.

There is an easy way to overstate this argument.

Sameness is not valuable only because variation was expensive.

People join a company already knowing Salesforce or Jira.

Consultants know how to implement them. A labor market forms around them. Integrations target them. Training and certifications exist. Answers are searchable. Thousands of customers discover bugs and edge cases together.

A common workflow can also make an organization better by pushing it toward a practice that has already been learned elsewhere.

Those effects are real.

The future is not “variation wins.”

It is:

Standardize where sameness creates leverage. Generate where difference creates value.

Why should every business share a payment protocol? There are enormous advantages.

Why should two companies with radically different sales motions use the same opportunity-review screen?

Much harder to explain.

Historically, the second question barely mattered because arbitrary variation was prohibitively expensive.

When variation gets cheap, sameness becomes a choice that needs a reason.

Anyone old enough to remember serious bespoke enterprise software should be nervous at this point.

We already tried letting every organization have its own software.

It produced enormous amounts of archaeology: mystery scripts, custom databases, frozen vendor forks, spreadsheets acting as critical infrastructure, and integrations nobody dared touch.

Customization gave us local fit and global incoherence.

AI can reproduce that disaster much faster.

The answer is not to avoid bespoke software.

It is to stop making the whole stack bespoke.

Stewart Brand’s idea of pace layers is useful here. Healthy complex systems contain parts that change at different rates. Fast layers experiment. Slow layers provide continuity.

Software is no different.

A dashboard can change tomorrow. A team’s workflow can change next month. The authoritative definition of a customer may need to survive for years. Identity and authority can survive generations of applications.

Problems arise when those layers become fused.

A temporary workflow gets baked into a data model. An org chart leaks into authorization. A UI assumption becomes an API contract. A local integration becomes the only place an important business rule exists.

Then fast change starts dragging slow meaning behind it.

The architectural rule for mass-customized SaaS is simple:

Standardize the slow layers. Generate the fast layers.

The point of strong architecture is not to prevent customization.

**It is to make customization cheap without making the system incoherent.**

The slow layers give the generated software something to push against.

A claims interface can change. The meaning of a claim should not casually change with it.

A team’s workflow can be regenerated next week. The identity model underneath it should not be reinvented because a generator found another representation more convenient.

A temporary reporting application can disappear. The authoritative financial data and audit trail cannot disappear with it.

Cheap variation is safe only when something durable constrains it.

The old bespoke era had another problem: every customization became something you had to maintain.

A customer modified version 4.2. The vendor shipped 4.3. Now somebody had to merge the changes.

Over time, custom software accumulated weight.

Generative software offers another possibility.

Suppose the durable things are not the generated implementation itself but the customer’s intent, applicable policies, architectural constraints, available capabilities, data contracts, provenance, and evaluations that establish acceptable behavior.

The implementation can be derived from those artifacts.

The workflow changes. Regenerate it.

The platform changes. Regenerate it.

The company reorganizes. Regenerate it.

This gives us something the old customization model did not:

**Customization without forks.**

There is a very large assumption hiding here.

Intent, constraints, provenance, and evaluations have to become durable enough that an implementation can actually be regenerated from them. If they are incomplete, stale, or wrong, regeneration will faithfully produce the wrong software.

That is the problem I have been exploring in [The Phoenix Architecture and my Regenerative Software work](https://aicoding.leaflet.pub/): if code becomes disposable, the knowledge required to recreate it cannot remain trapped inside the code.

If we can solve enough of that problem, the economics change dramatically.

A vendor no longer has to maintain ten thousand diverging implementations by hand.

It maintains a shared substrate plus the durable knowledge necessary to produce ten thousand variations.

The implementations become replaceable.

There is an obvious operational objection.

Who supports ten thousand different applications?

Who tests them?

What does SOC 2 or HIPAA certification mean if customer A and customer B are running different generated interfaces and workflows?

Customization without forks solves the source-maintenance problem. It does not automatically solve support, testing, security, or compliance.

If every variation is an unconstrained snowflake, mass-customized SaaS collapses under its own operational cost.

That is why the slow layer has to include more than APIs.

It needs a governed execution environment with common identity and authorization, telemetry, deployment controls, data contracts, security boundaries, policy enforcement, and evaluation frameworks.

A customer’s software can be different without being arbitrary.

Cloud platforms already do something analogous one layer lower. Millions of applications can be different because the infrastructure underneath them standardizes enough operational behavior to make that diversity manageable.

The next generation of SaaS may do the same thing above the infrastructure layer.

Different applications.

Common guarantees.

Support changes too. The vendor should not need a human support engineer to reverse-engineer every customer’s generated source code. It needs enough provenance, telemetry, constraints, and reproducibility to answer what was generated, why it was generated, what changed, and whether it remains inside the supported envelope.

Otherwise we have merely reinvented consultingware at AI speed.

This reframes the strategic question for software companies.

What are customers actually paying you for?

If the answer is mostly CRUD screens, generic workflows, dashboards, forms, approval logic, reports, and a configurable database, then the ground is moving.

Those things remain useful, but part of their historical value came from the fact that somebody had to write and maintain them.

If the answer is a trusted network, authoritative data, regulatory expertise, money movement, a system of record, an ecosystem, accumulated institutional knowledge, auditability, or operational responsibility, then cheap code does not reproduce the important part.

The visible application can shrink while the substrate becomes more valuable.

[IDC has described](https://www.idc.com/resource-center/blog/agent-supplier-or-featureware-the-choice-every-saas-vendor-faces-now/) one possible version of this future as SaaS applications becoming “featureware,” with agents owning more of the interaction while existing applications remain underneath as governed systems of record and capabilities.

I think the opportunity is more ambitious than accepting demotion behind an agent.

The best SaaS companies can deliberately become **substrate companies**.

They own the slow layer.

They make it safe to generate the fast one.

If I ran a SaaS company today, I would ask:

If every customer had a bespoke application tomorrow, what part of our product would they still need to share?

That question separates the application from the durable business underneath it.

For Stripe, the answer is obviously not a checkout form.

For a payroll company, it is not the employee table.

For a financial information company, it is not a dashboard.

For some companies, the answer will be substantial.

For others, it may turn out that most of the product lives in the fast layer.

That does not mean those companies disappear tomorrow.

It does mean they should probably be racing to discover what they own underneath the UI before somebody else does.

The same economics changes “buy before build.”

That advice made sense when building an internal application meant staffing a software project indefinitely.

But consider fifty employees losing twenty minutes a day to a workflow that poorly fits them.

That may not justify six months of custom development.

It could easily justify a few days of generated development on top of an existing substrate.

This can produce a renaissance in internal software.

Not giant IT departments rebuilding SAP.

Small teams maintaining strong shared foundations while producing highly specific tools around them.

Their advantage is not that they can type code better than a SaaS vendor.

It is that they know the organization: its language, policies, data, authority structure, exceptions, and history.

These are exactly the details generalized software has always had to abstract away.

Difference becomes the internal team’s comparative advantage.

There is a nightmare version of all of this.

Every team starts generating applications. Each creates another representation of customer identity, invents another permissions model, or makes another convenient copy of important data. Every agent gets whatever access makes the current task easiest.

Within a year, the company owns a thousand locally sensible applications that disagree about basic reality.

Generation makes this easier, not harder.

So someone still has to own the slow layers.

There needs to be authoritative data, shared domain concepts where common meaning matters, stable capabilities, authority boundaries, protocols, and constraints on what generated software is allowed to do.

The governance should match the pace.

A team should be able to regenerate its dashboard without an architecture committee.

Redefining who may move company money is different.

If every change requires central approval, customization dies.

If nothing requires it, coherence dies.

Good architecture tells us which is which.

The traditional enterprise decision was made at the application level:

Should we build a CRM or buy one?

Build payroll or buy it?

Build a support system or buy one?

That unit may be too large.

The better question is:

Which layers should we buy, which should we share, and which should we generate?

Buy the network.

Share authoritative data.

Standardize identity.

Reuse the regulatory engine.

Outsource the operational responsibility you do not want.

Generate the workflow, interface, reports, and orchestration.

Regenerate the things whose requirements change quickly.

Preserve the things whose meaning needs to remain stable.

A healthcare record should move slowly. The application one clinical team uses around it may move constantly.

An accounting ledger should move slowly. The CFO’s current reporting experience probably should not.

A customer identity should be durable. The sales workflow surrounding it can be peculiar to one company.

This is not build versus buy anymore.

It is build, buy, share, generate, and regenerate, each applied at the right pace.

Configuration starts with the product.

Here is our application.

Here are the dimensions along which we anticipated you might differ.

Tell us which values you want.

Generation can start somewhere else.

What are you trying to accomplish?

What data and capabilities exist?

What policies constrain them?

What does success look like?

Generate something appropriate.

That reverses the relationship between software and the organization.

For decades, organizations increasingly became instances of applications. They mapped themselves into the nouns, workflows, and screens provided by the software they bought.

Generative systems make another relationship possible:

**The application becomes an instance of the organization.**

That does not mean every difference is good.

It means difference no longer has to be rejected merely because it would have required another codebase.

The history of business software starts to look like three eras.

The first was bespoke: excellent local fit, terrible economics.

The second was standardized: packaged software and SaaS gave us extraordinary economies of scale by persuading enormous numbers of organizations to share applications.

The third may combine both.

Shared slow layers. Bespoke fast layers. Centralized operations. Local fit. Stable foundations. Replaceable applications.

The first SaaS era achieved economies of scale by eliminating variation.

The next one may achieve economies of scale while restoring it.

That is why I don’t think SaaS is dead.

Companies will still buy software as a service. Vendors will still host it. In many cases they may host even more of it.

What changes is the default assumption that the visible application must be substantially identical for everyone.

For the last twenty-five years, the software industry has asked an extraordinarily profitable question:

What application can ten thousand companies share?

The next era asks a different one:

What must ten thousand companies share so that everything else can safely be different?

One service.

Ten thousand applications.

SaaS isn’t dead.

**Sameness is.**