Before replacing SaaS subscriptions with internally built AI software, executives should evaluate the full lifecycle cost of ownership rather than focusing on development cost alone.
The key question is not whether the organisation can build a tool, but whether it has the capacity and resilience to maintain, secure, and continuously evolve it over time.
This includes assessing who will own the system long term, how knowledge will be distributed to avoid critical dependencies on individuals, and whether the organisation is prepared to absorb the operational burden currently carried by SaaS vendors.
A few weeks ago, a group of journalists from CNBC used AI coding tools to recreate the core functionality of the project management platform Monday.com over a single weekend.
The 💜 of EU tech
The latest rumblings from the EU tech scene, a story from our wise ol’ founder Boris, and some questionable AI art. It’s free, every week, in your inbox. Sign up now!
The result triggered a sharp drop in the company’s share price, a wave of commentary about a coming ‘SaaSpocalypse’, and an uncomfortable question in boardrooms around the world: if software can be rebuilt that quickly, what exactly are companies paying for when they buy SaaS?
Software has become dramatically cheaper to build. Internal tools that once required months of development, specialised teams, and significant budgets can now be created in days.
What previously required a structured engineering programme can, in some cases, be assembled in a weekend. Sometimes less.
That shift is now visible in procurement decisions. CIOs, CEOs, and CFOs are revisiting SaaS contracts already in place and those still being negotiated.
If software can be recreated internally at a fraction of historical cost, subscriptions begin to look less automatic. The question becomes blunt: if we can build it, why keep paying for it?
That question is incomplete.
It treats software as something you finish. You don’t. You run it.
Security updates arrive continuously. Integrations break without warning. Regulations shift. Internal workflows evolve. Users change their minds.
None of that is edge-case behaviour. It is the system.
In most cases, the real cost of software sits after deployment. Not before.
Software spends most of its life being maintained, not written. The work of keeping it stable, secure, and aligned with the business is where the majority of effort accumulates over time. AI has changed how fast software can be produced. It has not changed the burden of keeping it operational.
This is where SaaS and internal builds diverge.
SaaS vendors distribute maintenance, upgrades, and support across thousands of customers. That burden is absorbed into the product. When companies replace SaaS with internal systems, those responsibilities do not disappear.
They are absorbed internally and concentrated inside a single organisation, all while the company trades its old subscription fees for new ones to pay for the enterprise AI developer tools themselves.
What looks like savings at the point of purchase often becomes an operational load that only shows up later, when it is already embedded in teams and processes.
And it rarely stabilises. Software changes because everything around it changes. Each change creates work: fixes, updates, testing, and integration adjustments. Someone has to own all of it.
A second cost emerges alongside this.
Every system needs ownership. In SaaS, that ownership sits with the vendor. In internal builds, it moves inside the organisation. Roadmaps, incidents, support, and ongoing development tend to concentrate in a small number of people who understand the system in detail.
That creates a different kind of dependency. Companies often think they are removing vendor lock-in. In practice, they are replacing it with reliance on individuals.
And that is usually a worse trade.
If AI is used to accelerate development, the risk increases. Systems are assembled faster, but with less shared documentation and fewer durable reference points.
When the people who built them leave, what remains is software that is harder to interpret, harder to modify, and more fragile than expected.
The dependency has not disappeared. It has shifted.
This is why the build-versus-buy decision is not a cost exercise. It is a question of where operational responsibility should sit, and how much complexity an organisation is willing to own over time.
Before replacing SaaS with internal software, executives need to look beyond the initial build. They need to account for what comes after: maintenance, integration, security, continuity, and turnover.
The conclusion is not that companies should avoid building software internally. Many now should. AI has changed the economics enough to make that viable in cases that previously made little sense.
But it has only changed one side of the equation.
It has made software cheaper to build. It has not made it cheaper to run.
That gap is where most enterprise decisions will fail.
Before cancelling the next SaaS subscription, the question is simple: not whether it can be rebuilt, but whether the organisation is prepared to own everything that follows.
