---
title: "The SaaSpocalypse"
slug: "chapter-2-the-saaspocalypse"
kind: "chapter"
order: 3
label: "Chapter 2"
chapter: 2
part: "The Bill Comes Due"
partLabel: "Part I"
partNumber: 1
epigraph: "When the people who used to buy applications can build them, the application stops being the asset."
summary: "In the trade press the argument has a name, the SaaSpocalypse, and a familiar shape: enterprises are beginning to ask whether they should keep paying for software subscriptions when AI lets them bu…"
words: 1159
topics:
  - "What the debate is actually about"
  - "What a subscription was paying for"
  - "The three things that remain scarce"
  - "The headless conclusion"
  - "What it means for a CIO's portfolio"
---

In the trade press the argument has a name, the SaaSpocalypse, and a familiar shape: enterprises are beginning to ask whether they should keep paying for software subscriptions when AI lets them build applications themselves, and nobody is sure what happens to per-seat pricing when they stop. Like most arguments with dramatic names, the interesting part is not the prediction but the mechanism. This chapter is about the mechanism, and about the conclusion I draw from it for anyone who runs an institution's technology portfolio.

## What the debate is actually about

A software-as-a-service product bundles four things. A user interface. A data store, usually the vendor's. Business logic, encoded by the vendor's engineers. And an operating commitment: the vendor keeps it running, patched and compliant. For two decades the bundle was efficient, because building and running any one of those four was expensive, and buying all four for a monthly fee per user was cheaper than hiring the people to do it.

AI changes the cost of exactly one of the four: the business logic and the interface around it. A competent team with a coding agent can now produce a working internal application in days, where it once took a quarter. A less technical team with a capable agent platform can produce a useful one in an afternoon. The question the SaaSpocalypse asks is what happens to the price of the bundle when one of its components approaches zero.

The naive answer is that subscriptions collapse. The more careful answer is that the bundle unbundles, and the price moves to whatever is still scarce.

## What a subscription was paying for

Consider what an institution actually receives from a typical departmental SaaS product. A ticketing tool, say, or an advising platform, or a contract tracker. The interface is pleasant but generic. The logic is a set of forms and workflows that encode a reasonable default process, which the institution then spends months customizing. The data is the institution's own, exported from its systems of record, synchronized on a schedule, and held in the vendor's database where it is at best a copy and at worst a divergent one.

The operating commitment is the part that is genuinely hard to replace. Uptime, security patches, compliance evidence, backups, an on-call rotation. But notice that this commitment attaches to the data store and the runtime, not to the forms. If the forms can be regenerated in an afternoon, what the institution needs to keep paying for is a place to run them and a place to keep the data, under the institution's own governance.

That is the first half of the conclusion. The second half concerns what the regenerated applications need in order to be useful.

## The three things that remain scarce

An application generated by an agent is only as good as what it can reach. Three things determine that, and none of them is produced by the agent.

The first is live access to the systems of record. An advising app that cannot read the student information system is a demo. The connector that reads it, with the right permissions, through an audited path, is infrastructure, and it is reusable across every application the institution will ever build.

The second is identity. Every application needs to know who the user is, which organization they belong to, and what they are allowed to see. If each generated app solves this on its own, the institution has a hundred login systems and a hundred places where a token can leak. If identity is a shared service that applications consume, a new app inherits single sign-on, roles and session handling without writing any of it.

The third is the agents themselves, with their memory, their tools and their guardrails. An application is increasingly a thin surface over an agent that does the work. The agent, configured and governed once, is the asset. The surface is disposable.

Data access, identity and agents. These are what remain scarce when the application itself becomes cheap, and they are exactly the things a CIO should want to own rather than rent.

## The headless conclusion

Put the two halves together and the conclusion is what I call the headless application. The institution owns a platform that provides the three scarce things: connectors to its systems, a shared identity layer, and governed agents. Applications are generated on top of it as needed, for a department, for a semester, for a single process, and discarded when they are no longer useful. Some have a full interface. Many have almost none: an agent reached through a chat panel, a browser extension, a terminal, or an API call from another system. The head is optional. The body is permanent.

This inverts the SaaS economics. The institution stops paying per seat for a hundred vendors' forms and pays instead, on usage, for one platform it controls, plus the model tokens the agents consume. New capability costs engineering hours, or increasingly agent hours, rather than new subscriptions. And the data stays in the systems of record where it was all along, because the headless application never needed a copy.

I do not claim this happens overnight, or that every SaaS product is replaceable. Systems of record, the ERP, the SIS, the EHR, are not applications in this sense; they are the data layer the headless applications read. Specialized tools with deep domain logic will survive, at least for a while. But the long tail of departmental software, the tools that are mostly forms over the institution's own data, is where the SaaSpocalypse argument is simply correct, and that tail is where most of a CIO's subscription spend lives.

## What it means for a CIO's portfolio

Three practical consequences follow for anyone managing an application portfolio today.

Stop evaluating AI vendors as if they were SaaS vendors. The question is not which product has the best features. It is which platform leaves the institution owning the connectors, the identity layer and the agents when the contract ends. A hosted assistant with a superb interface and no way to take the configuration with you is a liability dressed as a product.

Start treating connectors and identity as capital investments. Every system of record connected through an owned, audited path is reusable by every future application. Every application built on the shared sign-in is one less place for credentials to live. These compound; subscriptions do not.

And plan the application estate for churn. If generating a departmental tool takes days, the estate will have more tools, shorter-lived, built closer to the people who use them. Governance has to move down into the platform, into the broker that scopes data access and the harness that constrains what agents may do, because it cannot keep up at the level of individual application reviews. The rest of this book is largely about how to build that platform so that the churn above it is safe.