Vibe Coding Our Way to 70%

The inversion that SaaS wasn't prepared for…

There’s an early signal I’ve now seen enough times in the wild that it’s hard to dismiss as anecdotal, even if each individual instance still sounds like one. Over the past few weeks, I’ve had multiple conversations with CEOs of tech startups who are starting to receive a version of the same feedback from potential customers: instead of buying software, prospects are increasingly deciding to vibe-code a solution themselves. Not because it’s better, but because it gets them far enough.

That “far enough” is landing, with surprising consistency, around 70%.

I raised this at a thought leader symposium in Dallas last week, expecting at least some pushback, and instead got immediate agreement. One firm owner said plainly that rather than paying $300/mo per user for an off-the-shelf product, the agent-built 70% solution is good enough in the current environment. Another chimed in (not a developer by any stretch) and said he’s been building things on the weekends simply because it’s fun. This isn’t just a cost decision, it’s a behavioral shift.

What’s striking is how quickly the boundary of what people “won’t build themselves” is collapsing. In an internal discussion at radical, the point was raised that surely there are still limits - that people aren’t going to start vibe coding their own general ledger. And if you read the recent briefing, someone had done exactly that. By his own admission, it wasn’t particularly good, and he wasn’t using a complex GL to begin with, but it worked for his business. Around the same time, I saw a CEO share on LinkedIn that he had spent a weekend building a replacement for HubSpot. Again, not best-in-class, but usable and to his own preferences.

Individually, these are easy to write off…together, they form a pattern. My instinct, honestly, is still that this has limits. Not every system will get vibe-coded into existence, but I’m increasingly unsure where those limits actually are. That uncertainty feels more important than whatever answer I’d have given six, or even three months ago.

TechCrunch has already leaned into the narrative of SaaSpocalypse, which may or may not be more marketing fodder than reality, but it points to something worth paying attention to. Because the more interesting dynamic here isn’t whether these self-built solutions rival existing software - they don’t. It’s that they don’t have to because the standard isn’t excellence anymore. It’s sufficiency, shaped by context, constraints, and increasingly, by a willingness to trade polish for control. What’s notable is that this isn’t just showing up in conversations, it’s already impacting markets. Last month, a single release from Anthropic triggered a roughly $285B selloff across the software sector.

It would be convenient to attribute this entirely to economic pressure. Budgets are tighter, scrutiny is higher, and software that once felt like a default purchase now has to compete for its place. That’s real, and it’s accelerating the behavior. The structural shift underneath all of this is simple: the cost of creating software has dropped below the perceived cost of buying it - and when that inversion happens, the starting point changes. You don’t begin with procurement, you begin with construction.

What sits underneath that shift, is that software is quietly moving from something standardized to something individualized. For the last two decades, SaaS has been built on a kind of implicit compromise: you adopt a system designed for the average user, and in return you get scale, reliability, maintenance and convenience. But when the cost of building collapses, that tradeoff starts to feel less necessary. Instead of adapting your workflows to fit a product, you can increasingly shape the product to fit your workflows. It’s messier, and often incomplete, but it’s also more precise…and for many use cases, that precision matters more than polish.

Pascal’s framing in the briefing around bifurcation is useful here, not as theory, but as a way to understand where this is going. We’re watching the market split between systems where completeness and trust are non-negotiable, and a much larger surface area where “good enough” is not just acceptable, but rational. The 70% threshold is emerging as the dividing line; above it, you still buy – but below it, more and more people are choosing to build.

I think what makes this particularly important, is that it reframes competition in a way that most companies aren’t prepared to handle. The threat isn’t another product with a better roadmap or a tighter feature set, it’s a user who decides they don’t need the category in the first place. A small business owner comparing a self-built ledger to Quicken isn’t benchmarking against enterprise accounting software. A founder assembling a CRM over a weekend isn’t trying to replicate HubSpot in full. They are solving a narrower, more individualized version of the problem - and in doing so, stepping outside the boundaries that defined the category. Jeff Seibert, the CEO of Digits, put language to this in a way that’s worth paying attention to, “the second-order effects will be fascinating. When software is cheap, it’s taste and distribution that matter.” This framing pulls the conversation out of tooling and into consequences.

And that opt-out dynamic is the signal.

Once someone successfully builds one thing, even imperfectly, the barrier to building the next drops dramatically. Capability compounds, confidence compounds, and what starts as experimentation begins to normalize into an alternative path: one that doesn’t rely on waiting for software to catch up to your needs, because you’ve already adjusted it yourself.

The implication isn’t that 70% gets better (although I’m sure that number continues to improve as the coding models mature) it’s that once users believe they can build for themselves, the default posture shifts from buying software to questioning whether they need it at all.

@Kacee