The Vibe-it-yourself fallacy (the instinct is right, the answer is wrong)

AI coding makes rebuilding the SaaS you use feel almost free. It isn't, because you were never paying for code. But the urge to build won't kill SaaS, it will reshape it forever

👉 Article originally posted on TTY

Why would you buy a tool if you can just build it with a few prompts? I keep hearing this argument everywhere, and often with complete sincerity, not just from vibe coders but from experienced engineers too. The so-called “SaaSpocalypse” that followed the AI wave wiped roughly $2 trillion off software stocks in a matter of weeks at the start of 2026, and the build-it-yourself trend is part of what is driving it.

I have to admit, I was running with the pack when I started my journey into what we called “vibe coding“ last year. This is usually the first phase of the agentic coding addiction: an intense rush that keeps you building day and night, pushing you past reason and convincing you that every new idea has to be built immediately.

The pitch is simple: stop paying for the SaaS products in your stack, usually your CRM, internal tools, dashboards, project management software, or some other piece of software you resent, and just burn some tokens to rebuild them yourself. After all, if agents are becoming highly compliant software engineers and the marginal cost of coding is approaching zero, then in theory you are only a few prompts away from building exactly the tools you need. The promise is a more self-sufficient stack, fewer external dependencies, and dramatically lower SaaS spending.

“All you need is Claude,” they say.

But as compelling as the idea sounds, I see several major flaws in that line of reasoning. And I suspect those flaws will remain true even as model quality continues to improve.

Building a (good) product is still tough

The most obvious issue is that any software we use today is usually far better than anything you could realistically build in a few days or weeks. The CRM is the textbook example, and, funnily enough, the exact tool I claimed I would replace last year. Shipping something that looks like a contact list takes an afternoon. But the deduplication logic, the two-way email and calendar sync, the permission hierarchies, the audit trail, and the dozens of silent integrations your team relies on represent years of work hiding beneath a deceptively simple surface.

And if you despise one of those tools, you can probably find better alternatives on the market (for instance, Attio, Folk or even Twenty if you’re into open source) rather than mobilising your own time, or your team’s, to rebuild one from scratch.

Yes, you can open Claude Code, or whichever agent you fancy this week, and quickly ship something that looks reasonably solid at first glance. But engineers do not necessarily build great products, and product people rarely design resilient, secure architectures. So if you want to build something solid enough to rely on, you are already looking at a two-person effort: product and architecture. Congratulations, you are now tying up two talented people who are spending time specifying, iterating, debugging, and maintaining something that is not your core focus, often a secondary task at best and a chore at worst. Once you factor that in, the tradeoff becomes far less obvious.

And let’s not be delusional. For the same reasons your own team is under pressure from an ambitious roadmap, shipping new features, fixing bugs, migrating away from legacy database systems, or preventing the cyber catastrophe that could cripple your company, other people are working just as hard on the product you are thinking about replacing with a few prompts over the weekend.

Of course, a lot of tools have become abominations over the years, even for decades, and using them can feel unbearable. But again, switching to a better alternative is usually preferable to building your own future legacy codebase. It is not a question of whether you can build it. It is a question of focus.

As Amine Saboni from Pruna.ai framed it, the same logic applies to buying SaaS as to using the cloud: when you pay for a SaaS product, you are not buying software. You are entering a responsibility contract between a customer and a provider. The buyer delegates product design, architecture, maintenance, and security to the vendor, precisely so they do not have to carry that cost themselves. Amine ties this back to a thread from antirez.

Agentic coding is no different from human coding. It generates codebases and architectures that must be maintained, on top of the ongoing demands of product design and user experience. That burden does not disappear with higher coding velocity. Some would argue it grows exponentially.

The good case for building

There are, of course, a few edge cases.

Sometimes you just need a minimal tool with no intention of expanding its scope. A tiny cog, a thin workflow layer that simply makes your life a little easier. Usually, it is something that runs in the background, or on command, with no external access and no need for future evolution. In that case, it is more a script than a product, and you should build it. Think of a webhook that drops a Slack alert when a deploy fails, or something that reshapes a weekly export nobody else ever looks at.

In some situations, pricing can also make off-the-shelf solutions economically irrational, and maintaining a subpar internal tool becomes the only viable option. Picture a per-seat product you would have to roll out to a few hundred occasional internal users, where the math simply stops making sense.

Or you may have a very specific, critical, and strategic need that existing tools simply do not address. Usually this is the thing that is your product: the matching engine, the pricing model, the core no vendor can sell you because it is your actual edge.

Any of these can justify building in-house. But overall, I think the core logic still holds.

But the urge itself is signalling a new era

For all those reasons, after the initial excitement, part of me returned to reason: building instead of buying is often the wrong decision. Still, I believe the urge people have to build anyway is one of the most interesting signals in software right now. And it is here to stay, which means it cannot be ignored. It will redefine how we think about, build, and sell products.

As mentioned earlier, cost can sometimes be a source of motivation, but I do not think most companies want to rebuild tools simply to pay less. They want their tools to bend to their needs, not just offer a layer of AI copilots and shallow customisation features.

And that is what vibe coding brought to the table. It shifted the goalposts for what customisation looks like, and closed, static tools are now expected to open themselves up and deeply facilitate agent workflows, even if that creates enormous challenges, not only technically, but also in how we think about, design, and price products.

More and more, customers will expect full control without depending on someone else’s roadmap. The SaaS companies that survive the next five years will be the ones that find the right balance: providing a solid architecture and a great out-of-the-box experience on one side, while also giving users deep flexibility to adapt the product to their own needs on the other, all while preserving security and stability.

We have spent a year arguing about whether “vibe coding” will destroy SaaS. I am fairly sure it will not. But the impulse that made us think it could is already reshaping what SaaS actually is. That is a huge challenge for incumbents, and a major opportunity for new players.