Imagine an operations manager who spends a Friday afternoon building a tool to manage supplier approvals. It replaces an awkward spreadsheet and a subscription nobody likes. By Monday, the team is using it.
Six months later, purchasing depends on it. Finance wants a different approval policy. A supplier disputes a decision, and someone needs to reconstruct what happened. The operations manager has moved to another role (true story, although not ops manager).
This is the part of vibe coding that interests me most: the long tail after the initial wow factor of vibe-coding an application. The toil of maintaining and operating software, which lurks after the glow of vibing has receded away.
I tried to find evidence of companies who initially vibe-coding their way into some software only to realize that the true cost is far greater than the initial build, but was unable to find good examples. I do know from my own interactions with customers that many have reversed decisions to vibe-code SaaS or other enterprise software and instead buy from software vendors whose entire raison d’être is building that software.
The closest I found was from Menlo Ventures’ “2025: The State of Generative AI in the Enterprise”, which admittedly is quite outdated in the age of AI.
In 2024, that confidence still showed in the data: 47% of AI solutions were built internally, 53% purchased. Today, 76% of AI use cases are purchased rather than built internally. Despite continued strong investments in internal builds, ready-made AI solutions are reaching production more quickly and demonstrating immediate value while enterprise tech stacks continue to mature.
The report, along with my own experience, suggests that some companies outside software are already abandoning vibe-coded internal tools. The reason is simple: software costs far more to own than it does to build.
Maintenance is not just fixing bugs. In business software, much of the work comes from the business changing around otherwise functional code. Requirements evolve, integrations drift, approval rules change, and new exceptions accumulate. At the same time, the technical environment underneath the application keeps moving. Databases need to be upgraded. Dependencies become obsolete or vulnerable. APIs change. Operating systems and runtimes reach end of life. CI/CD pipelines break or need to be rebuilt. Authentication standards change. Security teams discover vulnerabilities that require patches, configuration changes, or architectural work.
A recent build-versus-buy survey I was filling out made the tradeoff unusually clear. Its questions pointed directly at the hidden cost of vibe-coded software. They were not really about whether AI could generate the application; they were about what happens after it exists. Who supports it? How many systems does it connect to? What happens when it fails? How many teams depend on it? What data must be preserved? Are there audit or regulatory requirements? Those are not build questions. They are ownership questions.
None of this means the initial vibe-coded application was poorly built. Even good software becomes unsafe, unsupported, or incompatible as the business and technical stack evolve. That is the joy of software ownership :) That’s part of why SaaS and cloud broadly speaking is successful. It makes that software S.E.P
Cheaper creation will probably lead companies to own far more software than they intended. Each application will have a compelling origin story: a frustrating workflow, a quick build, an immediate improvement. The problem emerges only when those applications accumulate.
Before building another one, the useful question is simple: would we still choose to own this software if its upkeep appeared explicitly in next year’s budget and in someone’s job description? Would someone be responsible for operating and maintaining this software?
If the answer is yes, build it—and give it an owner and be explicit and transparent about the true cost.