The SaaS apocalypse has a maintenance problem
The latest season of AI hype brings us the SaaS apocalypse. Companies are waking up to the fact that they've been paying thousands per seat, per year, for software that mostly sits on top of their own data. With AI making it cheaper than ever to build, the obvious question follows: why are we still paying for this?
Build vs. buy is one of the oldest questions in software. The math just changed. But the logic behind the conversation hasn't caught up.
The hidden cost behind the AI hype
Every SaaS subscription has two costs. The one on the invoice: seat fees, annual renewals, the negotiation you have every December. And a quieter one: the way teams gradually reshape themselves around the tool. Workarounds become habits. Features that don't exist stop being missed. Over time, the software shapes the business rather than the other way around.
Internal tools carry their own version of this. Yes, the build cost is dropping fast. AI-assisted development is making it quicker and cheaper to get something working. The ownership cost isn't moving at the same rate. Someone still has to maintain it, make decisions when it breaks, keep it relevant as the business changes.
Then there's focus. Every internal tool your team builds and maintains is engineering attention pulled away from your actual product. Not just maintenance hours, but the context switching, the support requests, the "quick fix" that eats a Friday. The best historical example of this is the corporate intranet. Almost every company that ever had one built it with good intentions and promptly let it rot. It became the least-supported piece of software in the building, updated when someone complained and ignored the rest of the time. That pattern didn't start with AI and it won't end with it.
AI lowers the barrier to creation. It doesn't lower the barrier to ownership. The risk isn't that companies build bad tools. It's that they build more of them faster, and the graveyard fills up quicker than before.
So what's actually worth replacing?
Not all SaaS has the same moat, and the line is worth thinking through carefully.
If a tool is essentially a UI over your own data, and you can get that data out, the moat is shallow. The value lives in your data, not in the software holding it. Rebuilding the interface is tractable, and AI makes it more tractable by the month. Proposal software is a clean example: template-driven, DocuSign-ready, operating entirely on the customer's own data. The core function is document generation with variables. Building ScopeSmart taught us this pattern directly. AI-driven output replacing what previously required a dedicated product category. Tools like this are genuinely vulnerable.
Then there's software where the moat is real. Fraud detection, pricing engines, recommendation systems. Basically anything making algorithmic decisions at scale with years of domain-specific training behind it. These aren't UI problems. Replacing them isn't a sprint. It's a multi-year effort with no guarantee at the end.
The tricky ones sit in the middle. Customer service tooling like Zendesk or Intercom looks, on the surface, like a database with a UI. Your ticket and conversation data is yours and exportable. But the value is in the routing logic, the workflow automation, the integrations across the rest of your stack, the reporting your support team depends on every morning. You could rebuild it. The distance between "you could" and "you should" is usually larger than it looks.
Building got cheaper. Owning didn't.
What used to take teams weeks can now be done by a developer over the weekend with a 6 pack of Red Bull. That's a genuine shift, and it changes the calculation for a lot of product categories.
Building something new is exciting. Maintaining something old isn't. Nobody volunteers to pick up support tickets on a tool they didn't build, for a feature nobody documented, in a codebase that hasn't been touched in eight months. The developer who shipped your new internal tool on a high is not the same developer who wants to babysit it six months later. That's not a criticism — it's just how people work.
What it means in practice is that the cycle tends to repeat. The SaaS gets replaced with something custom and shiny. Excitement fades, priorities shift, the new thing gets quietly neglected. You haven't escaped the maintenance problem. You've just reset the clock. And the engineering hours spent building and then rebuilding aren't going toward the actual product.
Organisational capacity matters here too. The SaaS apocalypse story tends to assume a company with an engineering bench capable of absorbing maintenance without cutting into forward progress. For most smaller teams, replacing tooling means taking on a maintenance surface alongside building the actual product. That's a trade-off worth being absolutely clear about before making it.
Approaching build vs. buy in the age of AI
The question is older than the hype. Build vs. buy has always been a real decision, and the right answer has always come down to specifics rather than ideology. What AI changes is the threshold. More categories of software are now buildable at reasonable cost and speed, so the question comes up more often and for more things.
The framework for answering it hasn't changed though. The build cost is only one number in the equation.
Three questions worth sitting with before making the call:
-
Where does the value actually live? In our data, or in what the software does with it? If it's the data, it's likely replaceable. If the software is what creates the value (through computation, algorithms, years of domain-specific iteration) it probably isn't.
-
Can we actually own this, not just build it? Not the hours for the initial build, but the ongoing attention, the decisions, the willingness to prioritise it when something more urgent is on fire.
-
What's the focus cost? Every surface area taken on internally is attention not going toward the actual product. That compounds over time in ways that are easy to underestimate at the start.
The SaaS apocalypse is selective. The tools that survive will earn their keep. Either because they're genuinely hard to replicate, or because the real cost of building and owning an alternative turns out to be higher than the subscription ever was.
We already know AI makes building cheaper. The question is what you're signing up for after the build.