The SaaSpocalypse.

A client asked me last week what I thought about the SaaSpocalypse. Not whether it was real because they had already decided that, but what it meant for their software stack specifically. I’ve been asked some version of this in almost every client conversation: if AI can build software, why would companies keep paying subscription fees for it?

Not All SaaS Faces The Same Threat

From our conversations with clients, it seems that a key contributing factor in this decision is the risk associated with replacing a product. Products that seem to be the most exposed are point tools and workflow products, where the risk of replacing the product is fairly isolated and easy to mitigate. These are applications built around a specific task such as scheduling, form processing, basic reporting, and internal approvals. If the core value of the product is “convenience”, the economics of building a replacement AI-assisted custom solution can be attractive.

At the other end, legacy “systems of record” appear to face far less pressure. Enterprise platforms carrying years of proprietary data, compliance requirements, and broad organisational integrations aren’t easily replaced. The governance embedded in these systems often takes years to build properly, and AI coding tools don’t change that. AI agents actually need these systems to function, which makes the underlying platforms more valuable, not less.

The Calculation That Shifted

Historically, the question of “build vs. buy” was influenced by a few things, namely:
(1) The cost comparison of development spend and ongoing maintenance vs ongoing licence cost,
(2) the accessibility of the skills required to build a custom piece of software, and
(3) how dependent a company would be on internal resources to continue to maintain a custom solution?

On balance, buying a SaaS product edged ahead and made complete sense. Building custom software was expensive, slow, and risky.

That calculation has shifted. AI-assisted development has dramatically reduced the cost and time required to build custom tools. Custom software builds that were rejected or parked three years ago are now worth revisiting. This doesn’t mean every organisation should abandon its vendors. The question has moved from “can we afford to build?” to “should we build?” That’s a different question, and it requires a different kind of judgement. Not everything that’s now buildable is worth building. The filter has shifted from cost to strategy.

The trap nobody is planning for

The risk that gets less attention isn’t what happens if organisations keep paying for SaaS they no longer need. It’s what happens when they decide to build replacements and do it badly.

Spinning up an AI-assisted prototype is fast. Getting it into production, with proper security, cost controls, reliability, and the ability to change it over time, is a different problem entirely. A custom tool that works in a demo but blows the infrastructure budget at scale isn’t a SaaS replacement.

This pattern is already emerging. Organizations are building quickly and discovering that the hard work starts after the prototype, not before it. If the build decision isn’t paired with a serious plan for production-grade execution – security, governance, scalability – from the start, the SaaSpocalypse trade ends up costing more than the subscriptions it replaced.