Why are we still paying for this? That question is being asked more and more often in boardrooms and budget meetings, as teams look at another software subscription renewal or another platform that almost fits the way the business works and wonder whether they could simply build the thing themselves. A few years ago, the answer was usually no. Custom software meant hiring developers, waiting months for a working version, and spending a serious amount of money before anyone could say whether the idea was even a good one. Artificial intelligence has changed that calculation fast. Someone with deep knowledge of a business problem can now turn an idea into a working prototype in days, sometimes in hours, using tools that write the code from a description in plain language.
That is a genuine shift. But being able to build software is not the same as being ready to own it, and confusing the two is where the trouble starts. That is the heart of the new build-versus-buy conversation, reshaped by one of the most talked-about ideas in technology: vibe coding.
The term itself is barely two years old. AI researcher Andrej Karpathy, a co-founder of OpenAI and a former director of AI at Tesla, coined it in a post on X on 2 February 2025, describing a style of coding in which you give in to the vibes and forget that the code even exists. The phrase caught on so quickly that Collins Dictionary named vibe coding its Word of the Year for 2025, and AI-assisted building has since become a normal part of everyday work.
The case for building software inside the business has rarely been stronger. The cost of testing an idea has fallen sharply, but the bigger opportunity is relevance. The people inside a business understand its problems in ways an outside vendor often cannot. A finance team knows exactly where its invoicing process breaks down, and an operations manager knows which system people actually rely on, whatever the official process says on paper. AI now gives the people closest to those problems a far greater ability to shape, prototype and test the software meant to solve them. Retool’s 2026 Build vs Buy report found that 35 per cent of the builders it surveyed had already replaced at least one software product they used to pay for with something built in-house.
Building makes particular sense when the software captures knowledge that is unique to the company, when it directly improves the value the business offers its customers, or when it gives the business greater control over its own data. But something that is easy to build does not automatically become worth owning, and that is where vibe coding can mislead people.
AI has dramatically reduced the cost of getting to day one. It has not removed day 500. Software still has to keep working long after the excitement of the first working version has faded. Programming interfaces change, security flaws appear, and business processes evolve. Someone still has to test, patch, monitor and support what was built. A finance associate might put together an invoicing application over a weekend. Six months later, dozens of people may depend on it and sensitive financial data may flow through it every day. At that point, the question is no longer who built it. It is who owns it.
Security makes this even more important. Veracode’s 2025 GenAI Code Security Report found that 45 per cent of the AI-generated code it tested had security weaknesses, a sobering figure for any business handling sensitive customer, financial or health data. That does not mean companies should stop building with AI. It means that once software moves from an experiment to something the business depends on, it needs proper IT involvement, security, governance and clear ownership.
The new economics of software does not mean every subscription should be cancelled. If an existing platform already solves a common business problem well, rebuilding it in-house may simply move the cost from a vendor’s invoice into the company’s own payroll. Before a team says, let us just build it, three questions are worth asking honestly. Does this genuinely make the business different? Who owns it after launch, not who can build it today, but who will maintain, secure and support it years from now? And have we counted the cost of ownership, or only the cost of creation? The first version might be cheap, but the software lifecycle is not.
That distinction is becoming central to how serious organisations think about building with AI. Non-technical teams should absolutely experiment and prototype. But when an application becomes important to how the business runs, it needs to be treated as something the business intends to own, with all the responsibility that implies. Once a prototype becomes part of how a business operates, the question changes. It is no longer: can we build this? It is: are we prepared to own it?
This argument was put forward by Anushay Rashid, Alpha Lead at JBS, in a piece on how AI has changed the economics of building software.
