Is This the Decline of SaaS and the Rise of Vibe-Coded Replacements?

Earlier this year, a wave of anxiety swept through the software market. Investors marked down software companies, commentators reached for the word apocalypse, and a question started landing in boardrooms that don't usually follow developer tooling. If anyone can describe what they want and have an AI build it, why keep paying for software at all? The nickname stuck. People called it the SaaSpocalypse.

It's a fair question, and it deserves a better answer than the two on offer. One camp says SaaS is finished and every subscription is now optional. The other says nothing has changed and it's all noise. Both are wrong, and the space between them is where the useful thinking lives.

Start with what's real, because there is something real here. The cost of building software that's good enough for a specific job has fallen sharply.

A team that would once have shopped for a tool, sat through demos, negotiated a contract and adapted its processes to fit can now describe what it actually wants and have a working version back the same week. That changes the maths. The build-versus-buy line, which sat in roughly the same place for two decades, has moved.

Some SaaS is genuinely exposed by this. The most vulnerable products are the single-purpose ones, the tools that are really a tidy interface sitting on top of a database. You weren't paying for something hard. You were paying for the convenience of not having to build it yourself. When that convenience costs an afternoon rather than a quarter, the subscription starts to look like a tax. Examples are already emerging of teams quietly replacing a reporting dashboard, a niche workflow tool, or a thin slice of their marketing stack with something they built in-house. The per-seat fee disappears. So no, this isn't pure hype.

But here's where the decline narrative goes wrong, and it's the same mistake organisations made the last time a new way of building software arrived. It confuses creating software with operating it.

The Hard Part Was Never the Features

The hard part of SaaS was never the features. It was everything wrapped around them. Authentication and access control. Keeping one customer's data away from another's.

Compliance with rules that change without warning. Knowing where data is processed and under what terms. Connecting to other systems, some of them old and temperamental, and keeping those connections alive. Staying up. Getting patched. Having someone accountable when it doesn't.

Vibe coding has collapsed the cost of the first part and changed almost nothing about the second. Generating a tool is now easy. Running one safely, for years, as requirements shift and people come and go, is exactly as hard as it ever was.

This is why the systems that look most replaceable on a screen are often the least replaceable in practice. A finance tool that handles regulated transactions, a platform that integrates hundreds of external partners, a system of record that the whole organisation trusts as the single source of truth: these earn their cost in the unglamorous work of staying correct under pressure.

You can prompt your way to something that looks like them. You can't prompt your way to the decade of edge cases, the regulatory coverage, and the accountability that make them safe to depend on. The deeper the complexity and the higher the stakes, the more a managed product is worth, not less.

The Hidden Bill

So the honest test isn't whether a tool can be rebuilt. Most can. The test is what happens after you rebuild it. That's where the hidden bill arrives.

Cancelling a subscription removes a visible, predictable cost and replaces it with an invisible, unpredictable one. The vendor wasn't only selling you features. It was carrying the security patching, the uptime, the compliance work and the responsibility, and absorbing it across thousands of customers.

Replace the tool and that burden doesn't vanish. It moves to you, and often onto one person, the one who built it. When the underlying model changes, or an API shifts, or that person leaves, who fixes the thing the finance team now depends on? A replacement that's cheaper on day one can be far more expensive by year two, and the cost shows up in exactly the places a quick build tends to skip: security, data protection, and the slow accumulation of code nobody fully understands.

This is the part the SaaSpocalypse conversation consistently glosses over. The efficiency gain is real. The freedom from per-seat pricing is real. But neither of those things resolves the operational question of who is accountable for what you've built.

The Case for Building. Done Properly

None of this is an argument against building. It's an argument for building with the right support around it.

When an organisation replaces a SaaS subscription with something it has built, it gains something genuinely valuable. Not just cost savings. Ownership.

A system designed around its actual processes, not adapted to fit someone else's product roadmap. A tool that works the way the business works, for the people who use it, without the compromises that come with buying something generic.

That's not a small thing. The efficiency gains that come from software built precisely for a specific operation are real and shouldn't be dismissed. The freedom that comes from owning the system, rather than renting access to it, compounds over time.

You decide when it changes. You decide what it prioritises. Nobody can price-hike you off it or deprecate the features your team depends on.

But those advantages only hold if the operational weight that a SaaS vendor was carrying has somewhere to go. And that's where the model most organisations are currently using breaks down. They're building the tool and assuming that's the whole job. It isn't.

What a Managed Service Relationship Actually Provides

The organisations getting this right aren't treating vibe coding as a replacement for expertise. They're treating it as a way to build something worth having expertise applied to.

The practical model is this. You use AI-assisted development to build a tool that fits your business precisely. You bring in an external technical partner, a consultancy with the right capability. They review what's been built, assess its security posture, validate the data handling, and identify what the person who built it couldn't see. And then, rather than hoping that tool stays functional on its own, you put it on a managed service basis.

That managed service relationship replaces what the SaaS vendor was quietly doing. Security patching. Monitoring. Updates when the underlying models or APIs shift. Accountability when something goes wrong. The difference is that you own the system. You own the intellectual property. The tool is built around your processes and your people, not the other way around.

This is the combination that makes the economics work long-term. The efficiency gain from a precisely built tool is genuine. The freedom from per-seat pricing is genuine. The ownership advantage is genuine. But all of those things depend on the operational layer being in place. Without it, the advantages are temporary and the risks accumulate quietly.

An external consultancy brings something else that's easy to underestimate. The person who built the tool with a language model doesn't know what they don't know. They can't audit what they can't see. A technical partner with real delivery experience can look at what's been built and tell you what the AI got right, what it skipped, and what sits in the gap between a working demo and a system you can safely depend on.

A Portfolio Decision, Sorted by Risk

None of this means leaders should ignore what's happening. It means the question has changed shape. It used to be build or buy, decided largely on cost. The sharper version now is this: what is this tool actually for, who depends on it, what's the worst thing that happens when it breaks, and who is accountable for it when it does?

Answer those, and a sensible pattern appears.

It isn't an apocalypse and it isn't business as usual. It's a portfolio decision, sorted by risk rather than by price. For low-stakes, internal, single-team tools, where you control the data and the worst case is a bit of inefficiency, building your own is often the right call and the savings are genuine.

For anything that touches customer data, regulated information, financial decisions, or a web of other systems, the operational weight is the whole point, and that's precisely what a vibe-coded replacement is least equipped to carry alone.

Most organisations will end up in a hybrid: buy the platforms where running them is the hard part, build around the edges where you can see the whole blast radius, and govern whatever you build with the same seriousness you'd expect from a vendor.

The organisations that come out of this ahead won't be the ones that vibe-coded the most replacements. They'll be the ones that knew which software was safe to replace, built it properly with the right support, and put the operational infrastructure in place to keep it that way.

Ownership Without Accountability Is Just Risk With a Different Name

The thing that makes replacement genuinely attractive, ‘AI writing the code’ is also the thing that hides what's missing. The person who built the tool may not be able to see what it's missing, and a tool that works in a demo can fail an audit.

Ownership, data rules, external review, and ongoing managed support aren't optional extras. They're the difference between a useful tool that compounds in value and a quiet liability that compounds in risk.

Speed without judgement isn't a saving. It's a deferred cost.

So is this the decline of SaaS? Not quite. What's declining is the era of paying a subscription for software whose only real value was that you couldn't easily build it yourself. That's a healthy correction, and it should make every vendor sharper and every buyer more deliberate.

But the organisations that benefit most from it won't be treating vibe coding as a shortcut. They'll be treating it as a capability, one that's most valuable when it's paired with the technical oversight, governance discipline, and managed support that turns a quickly built tool into something the business can genuinely depend on.

Working that out, tool by tool, is a strategic exercise, not a technical one. It's the conversation worth having before the subscriptions come up for renewal, not after the first thing you replaced stops working.