Why should I buy software or SaaS if Claude or Codex can build exactly what I want?
INTRODUCTION
AI and Vibe Coding are seemingly killing one major advantage of software and SaaS companies: that it takes special skills to design and develop great software. AI is rapidly collapsing the cost of software development. And more than that – AI coding helps you to build exactly the software you want. Customization to your exact problem at the highest possible level.
Unfortunately, once you look behind the curtain of a seemingly new age of software and SaaS, you will discover that designing, programming and even publishing software is only the first piece of a much larger puzzle. A puzzle that unveiled itself to every software entrepreneur in the past 50 years.
In my past 25+ years as a software entrepreneur the question of build versus buy has always been relevant and important. Myriads of consultants wrote custom software for large corporations. In-house enterprise developers developed entire portfolios of custom software. Typically, those software projects were successful – for a certain period. The break point typically came when an important change to the software required the expertise of the original team. But that too often wasn’t available anymore. Consultant teams had moved on, as had employees. Or documentation was non-existent or too scarce to make sense of. Those were often the exact circumstances driving the decision to replace custom in-house software by a professional business solution from a proven vendor. In the end, it was both an economic and risk-driven decision.
In my opinion, the situation is not fundamentally different in the age of AI coding. But one important part of the equation has changed dramatically: the cost and speed of creating software. AI is making software cheaper to build. But building software and owning software are two very different things.
So, does AI make software development faster? The answer appears to be: it depends. A controlled GitHub Copilot experiment found developers completing a bounded coding task 55.8% faster.
(Source: Microsoft Research — The Impact of AI on Developer Productivity: Evidence from GitHub Copilot https://www.microsoft.com/en-us/research/publication/the-impact-of-ai-on-developer-productivity-evidence-from-github-copilot/)
Yet a 2025 randomized study by METR found experienced developers working in their own mature codebases took 19% longer with AI.
(Source: METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity https://time.com/7302351/ai-software-coding-study/)
The contradiction is revealing. AI appears exceptionally good at accelerating code creation, while the economics become less obvious as context, complexity and existing software enter the equation
The current state of vibe coding allows almost everybody with decent domain expertise to quickly design, program and deploy software products which do not require complex architecture.
As applications become more complex and business-critical, the challenge increasingly shifts from generating code to verifying the resulting system: its architecture, behavior, resilience, security and interactions with everything around it. AI can help with these tasks as well, but complexity does not disappear simply because code becomes easier to generate.
(Source: Stack Overflow — 2025 Developer Survey: AI https://survey.stackoverflow.co/2025/ai)
However, the code itself is only one part of the lifecycle of a successful software product. Someone still needs to operate it, secure it, maintain it, document it, integrate it, support its users and take responsibility when something goes wrong. AI is rapidly closing the software creation gap. It is narrowing yet not closing the software ownership gap. And that changes the Build-versus-Buy equation, but perhaps not in the way many people currently expect.
Let’s have a look.
Building is Becoming Cheap. Owning Isn’t. The Ownership Gap Is Real.
Operations is certainly the most obvious task that starts once a software or SaaS is launched. Simply, you must make sure it’s running and available. You need to deploy proper monitoring, incident response plans, data backups and a lot more. Proper operations also include customer support, answering smart and “stupid” questions alike. In a typical SaaS environment that is the job of the vendor. When you vibe-code, it’s yours.
Maintenance covers code and product evolution, bug-fixing and adding all those little feature enhancements customers need. Well, that is usually something that is reasonably easy at the very beginning. However, the longer the product is deployed, the access to the original “inventor” and project owner becomes increasingly difficult. Every software developer knows that it is hard to understand your own code after a few weeks or months. People moving on to new positions or even jobs create even bigger problems. AI might be of help here, yet missing access to the original ideas, concepts and architecture and missing documentation becomes as crucial as ever.
There is, however, an important counterargument. AI will not only make software easier to create. It will also make software easier to maintain. AI can help developers understand unfamiliar code, generate tests and documentation, identify bugs, perform migrations and implement changes. Future coding agents will certainly become much better at maintaining existing applications.
But this advantage is not limited to the individual vibe coder. Software vendors use the very same technology. And this is where the economics become interesting: a SaaS vendor can apply these productivity gains across hundreds or thousands of customers, while an organization building its own solution applies them to one. AI therefore reduces the cost of software ownership on both sides of the Build-versus-Buy equation. It does not eliminate the economies of scale of a software vendor.
Very little enterprise software lives on an island. Applications need identities and permissions, APIs, data from other systems, audit trails and integrations with existing platforms. They become part of an ecosystem. AI can certainly help create these integrations faster. But somebody still owns them. APIs change. Authentication mechanisms change. Data models evolve. Systems are replaced. What started as a few lines of AI-generated integration code can become a long-term dependency between business-critical systems.
This is another example of the software ownership gap: generating an integration is becoming cheap. Owning it for the next five or ten years is not.
Managing Security and Trust as an Ownership Challenge
Security certainly is one of the prevailing topics of operating IT infrastructure. AI-generated code must be treated like any other unverified code: reviewed, tested and secured. Current research suggests this is not optional. Veracode’s 2025 GenAI Code Security Report found that 45% of generated code samples failed its security tests.
(Source: Veracode — 2025 GenAI Code Security Report https://www.veracode.com/blog/genai-code-security-report/)
Moreover, operating software securely is a complex task. It requires continuous adjustments and enhancements. Vendors are usually judged by how well their security operations function. They build trust through processes, certifications, pen tests and many more measures. Achieving the same level of security for a vibe coded and self-hosted solution requires taking on many of the same security responsibilities as a professional software vendor.
From Shadow IT to Vibe-Coded Shadow Software
There is another consequence of AI coding that I believe enterprises are beginning to confront: vibe-coded shadow software. SaaS gave us shadow IT – departments subscribing to applications without central IT necessarily knowing about them. AI coding takes this one step further. Employees will increasingly create applications themselves. Who knows that these applications exist? What data do they process? Who has access? Which APIs and libraries do they depend on? Who reviews their security? Who maintains them when their creator changes jobs?
The easier software becomes to create, the more software organizations will create. Ironically, this is going to make software governance even more important.
Code Stops Being a Differentiator
There is a fundamental argument about differentiation: if everybody has access to increasingly capable coding AI, code itself becomes less of a differentiator. The more interesting question then becomes: what makes one software solution better than another? It might be proprietary data, deep domain knowledge (deeper than the AI!), a better understanding of customer workflows, exceptional UX, integrations, operational excellence or simply years of learning from thousands of customers.
A software or SaaS vendor usually accumulates an abundance of domain expertise from dozens, hundreds or even thousands of customers. So might a consultant. And maybe your coding AI to a certain point. Of course, a specialist will have very specific and local expertise related to his job and environment which can be an advantage and will certainly be a strong argument for vibe coding a custom solution. And an argument against any generic software that can’t be easily customized to a specific problem or process. While this is true, your specific process or solution might not necessarily be the best, while a product vendor will usually implement the most common and proven solution to a problem. So, domain expertise is a double-edged sword, and you need to be aware of it.
AI can help turn ideas into software much faster. But deciding what should be built, how it should work and what makes it substantially better remains the more difficult problem. This applies equally to companies building their own software and to SaaS vendors. In fact, I believe AI will put significant pressure on mediocre SaaS products whose primary value proposition is simply that somebody already programmed them. AI is simultaneously bad news for some SaaS and good news for strong SaaS.
Responsibility: The Ultimate Ownership Question
This last point is a fundamental, maybe the most fundamental one. Whatever your AI codes for you, in the end you remain responsible. Whatever is injected into that code, whatever bugs or security flaw it contains, those are on you. AI can transfer the capability to create software to almost anyone. It cannot transfer accountability for security, privacy, compliance, availability, data loss or business continuity.
Revisiting Build versus Buy
All of this does not mean that Buy will win over Build. Quite the opposite: I believe AI will significantly move the boundary between the two.
Small internal applications, specialized workflows, temporary solutions, prototypes and software addressing very specific company processes will increasingly be built rather than bought. Many applications that were economically unreasonable to develop five years ago can now be created in hours or days. And that is a good thing.
The strategic question is therefore no longer simply, “Can we build this ourselves?” Increasingly, the answer will be yes. The better question is: “Do we want to own this ourselves?” A useful rule might be:
Build where uniqueness creates value. Buy where ownership creates undifferentiated burden.
This changes the economics on both sides. AI makes Build attractive for a much larger class of applications, while simultaneously raising the bar for what is worth buying. SaaS products whose value is primarily the code behind a set of features will face pressure. Products that remove substantial ownership burden while delivering domain expertise, reliability and economies of scale may become more valuable, not less.
So, here is a potential framework you might want to use:
My Conclusions
My prediction is therefore not that AI coding will disappear once the current hype settles. Quite the opposite. AI coding will become a normal and extremely powerful part of software development.
But I also don’t believe it will kill SaaS. AI will redraw the boundary between Build and Buy. At one end, simple and highly specific applications will increasingly be generated inside companies. This will put pressure on SaaS products whose main value proposition is simply providing functionality that used to be expensive to program.
At the other end, complex and business-critical software will increasingly have to justify its existence through much more than code: domain expertise, reliability, security, compliance, integrations, support and continuous innovation.
And software vendors have another structural advantage: they can spread the cost of all of this across hundreds or thousands of customers. So perhaps the biggest disruption AI brings to the software industry is not that everybody can suddenly become a software developer. It is that software development itself becomes less valuable relative to software ownership.
AI does not necessarily destroy SaaS economics because AI productivity is available to both sides, while SaaS retains economies of scale. With software and SaaS vendors experiencing the same productivity gains as any vibe coder, designing and operating great software again boils down to almost everything beyond coding.
For the last few decades, Build versus Buy was partly a question of whether you could afford to build something yourself. In the age of AI, the answer will increasingly be Yes. The question is whether you really want to own everything that comes with it.
