AI is changing the old build-versus-buy debate. Businesses can now create working software faster, cheaper and with fewer specialist skills than ever before. But as the barrier to building falls, we risk overlooking the harder question: who owns what happens next?
By Rob Gilbert, Managing Director of Commercial and Infrastructure at Totalmobile
There has always been a build-versus-buy debate in software. What AI has done is make that debate much more interesting.
You could always build your own software if you really wanted to. In the same way, you could build your own car. The question was whether you had the skills, time and money to make something you would actually trust.
AI is narrowing that gap very quickly.
We are now seeing what has become known as “vibe coding”: using natural-language prompts and AI tools to create software with far less conventional coding. And some of the results are impressive.
A few years ago, if you tried to build an application without a proper software development team, it probably looked like it. It might have been functional, but it would feel homemade.
Now you can create something in a short space of time that looks remarkably like enterprise software. That changes things.
But we need to be careful about what conclusion we draw from it.
Building software is not the same as owning it
There has been plenty of talk about a potential “SaaSpocalypse”, where AI allows businesses to replace established software platforms with applications they build themselves.
That is probably overstated, particularly when we are talking about systems that organisations rely on as systems of record.
A recent Reuters Breakingviews analysis reached a similar conclusion. It argued that while vibe coding poses a genuine challenge to traditional software companies, issues including security, auditability and scale make replacing core enterprise platforms a very different proposition from quickly creating an application.
That distinction matters.
AI is a huge force multiplier. It can help a relatively small team create things that would once have required significantly more time and resource. But the risks are still the risks.
Who tests the software? Who secures it? Who maintains it when something changes? Who supports it when it goes wrong? And who understands it two years later when the person who created it has left?
Those things aren’t particularly exciting. They are also a large part of what makes enterprise software enterprise software.
If you build your own car, you’ve got no warranty. You’re warranting your own car.
The same principle applies here. Buying established software isn’t simply buying the code. You’re buying the expertise, support and accumulated experience around it. When a problem emerges, you’re benefiting from somebody having seen versions of that problem before.
With something you’ve built yourself, you may only discover the problem the hard way.
Security doesn’t disappear because development gets easier
This becomes even more important as AI moves from helping people write code towards autonomous agents that can take actions within live systems.
The National Cyber Security Centre has issued guidance on managing the cyber risk of agentic AI. Its message is quite practical: as autonomy increases, organisations need appropriate safeguards, human oversight, monitoring and the ability to intervene when something goes wrong. For higher-risk uses, it recommends making named individuals or groups responsible for agent activity.
That gets to the heart of this.
AI may dramatically reduce the effort involved in creating an application. It does not remove accountability for that application.
In some respects, it makes accountability more important.
The easier it becomes for people across an organisation to create applications, workflows and agents, the easier it also becomes to create a new kind of technology sprawl. One useful tool becomes five. Five become 50. Then somebody has to work out what they all do, what data they access, whether they are secure and whether anybody is still maintaining them.
Speed at the front end can create complexity at the back end.
So where should businesses build?
This isn’t an argument against building things with AI. Far from it.
There are areas where this technology is going to be incredibly useful.
If you’ve got a niche requirement, for example, why wouldn’t you explore it?
Perhaps you need a small widget, a particular way of surfacing information or a simple workflow that is unique to your organisation. Historically, that might have ended up in a spreadsheet, or sat in a development backlog because it wasn’t important enough to justify the cost.
AI changes the economics of those smaller gaps.
It can also change how customers and software providers work together. Requirements gathering today can still be surprisingly analogue. People spend weeks describing what they want in documents, statements of work and meetings.
Imagine instead being able to create a rough prototype and say, “This is what I mean.”
That could make conversations about software much faster and clearer. Instead of trying to interpret an idea from a document, you can see it. It doesn’t need to be production-ready software. It can simply be a much better way of explaining the requirement.
So perhaps the future isn’t really build or buy.
It is knowing what to build, what to buy and where the two should meet.
The question has changed
The evidence suggests developers themselves already understand some of these boundaries.
The 2025 Stack Overflow Developer Survey found that 84% of respondents were using or planning to use AI tools in development. Yet 66% said a major frustration was AI producing solutions that were “almost right, but not quite”, while developers showed considerably more resistance to using AI for higher-responsibility tasks such as deployment and monitoring.
That’s a useful reality check.
AI is making it easier to build software. That’s a good thing. It will unlock ideas that previously weren’t viable and allow organisations to solve smaller, specific problems themselves.
But we shouldn’t confuse a lower barrier to entry with a lower burden of ownership.
The interesting question for CIOs isn’t whether AI means they can now build their own software. Of course they can. The question is: what are you prepared to own when you do?
