The Build vs. Buy Paradigm Has Flipped — But Not Where You Think
- 3 days ago
- 5 min read
A $600,000 Salesforce contract, gone in two months. A decade-long SAP transformation, still grinding through year six somewhere. I've spent enough time inside enterprise-scale builds to know exactly why those two stories aren't the same story — and that gap is what's actually worth talking about.
I read Fred Turner's story a few times before I let myself believe the number. The CEO of a health insurer called Curative went on a podcast and said his team built a replacement CRM using AI-assisted coding in about two months and then cancelled a $600,000-a-year Salesforce contract because of it. His Anthropic bill has apparently grown sixfold since. He's now going after 80% of the company's entire SaaS spend.
I've spent a chunk of my career on the other end of this exact question — years inside enterprise transformations where "should we build this ourselves" was a genuine, agonised, multi-month conversation, not a two-month build. So, a number like that gets my attention in a way it probably doesn't for people who haven't experienced a long, drawn-out digital transformation of sorts.
Curative isn't alone. A 55-person property management firm in Atlanta saved about $100,000 a year replacing Salesforce with something built on Claude Code. A rugby team in Seattle did the same thing to their ticketing platform and lifted revenue 25% in the process. One agency founder built himself an entire little operating system — CRM, proposals, client portal, payments — and quietly cancelled four subscriptions.
The SaaSpocalypse thesis: that AI coding tools will challenge software companies
Marc Benioff, unsurprisingly, isn't having it. He told investors in February he's still seeing "incredible demand" for Salesforce and coined his own term for the moment — not a "SaaSpocalypse" but a "SaaS-quatch," his bet being that AI agents make existing platforms more valuable, not less, because more work is now running through them than before.
I actually think they're both right. And figuring out why is more useful than picking a side of the build vs buy debate.
What Actually Changed in the Build vs. Buy Calculus
For twenty years, the build vs. buy maths was pretty stable. Building something yourself was slow and expensive. Buying a subscription was fast and cheap. You didn't need a framework to make that call most of the time — the answer was usually obvious the moment you scoped it out.
AI-assisted development has genuinely broken one side of that. I've watched this happen in my own work — something that would have taken a small team a proper quarter to build, test, and integrate now realistically takes a couple of weeks, sometimes less, if the workflow is well understood and someone competent is steering it.
What I don't think gets said enough is that the other side of the equation moved too, in the opposite direction. Subscription pricing has crept up everywhere. AI "feature" surcharges are showing up at renewal whether you asked for the AI feature or not. Lock-in has gotten deeper, not shallower, as these platforms wedge themselves further into how a company actually operates. The point where "just buy it" stops being the obvious answer has moved a lot closer than most people evaluating a renewal this year have actually clocked. A lot of us are still running 2022 maths on a 2026 decision.
2022 maths on a 2026 decision
Where This Genuinely Applies — and Where It Really, Really Doesn't
Here's what I noticed going through every one of these stories: they all have the same shape. A well-understood, internally scoped workflow. A small, motivated team. A system a handful of people could genuinely hold in their heads end to end. Curative's CRM, the property manager's client records, a ticketing system for a rugby team — all bounded contexts, all knowable, all small enough that a couple of good engineers can actually own the whole thing.
That is not the shape of an SAP transformation. I've been close enough to a few of these to know exactly why they run for years and cost tens of millions, and it was never really about how fast anyone could write code. It's integrated financial controls. Statutory obligations across half a dozen jurisdictions. Process dependencies wired into every part of a large organisation, where changing one thing quietly breaks three others nobody remembered were connected. AI writing code faster doesn't touch any of that. The bottleneck in that world was never typing speed.
So, when I see the Curative number get waved around as evidence that "building beats buying now," I want to be careful about what it's actually evidence of. It's evidence that a specific kind of problem, at a specific scale, has genuinely flipped. It's not evidence that the calculus has flipped everywhere and applying that two-month CRM logic to a genuinely enterprise-scale, compliance-heavy system is a good way to have a very bad year.
The Part of This Story I Actually Worry About
The bit that gets less airtime than the dollar figures is the one I keep coming back to: a lot of this newly built software is going up completely outside any formal governance, because the tools got fast enough to outrun the process that used to review them. I read a good, honest piece from a technical writer covering exactly this wave of CRM replacements, and the line that stuck with me was simple — vibe coding is fast to create, and a lot harder to secure, scale, and maintain. The savings on the slide can look great in month one. They can evaporate fast if the person who built it leaves, or a platform update quietly breaks an integration nobody wrote down anywhere.
I'm not saying don't build. I've built plenty. I'm saying the moment you save that $100,000, you've also just created a system somebody needs to genuinely own — the same way you'd expect to own any other piece of production infrastructure. Not left running because it worked when it shipped and nobody's checked on it since.
What I'd Actually Ask, If I Were You
Forget "should we build or buy." That's not specific enough to be useful. The question I'd actually sit with is this: is the thing you're looking at a bounded context, well-understood process a small team could genuinely hold in their heads — or does it live inside a web of compliance, integration, and organisational complexity that no amount of faster code-writing actually shortens?
is the thing you're looking at a bounded context, well-understood process a small team could genuinely hold in their heads
Curative's CRM was the first kind. A financial and operational backbone running an entire enterprise is the second kind. Most of what any of us are actually deciding sits somewhere in between those two, and the honest answer requires being specific about which side of that line you're really on — not borrowing a headline number from a story that was never solving your problem in the first place.
This article was written by Keith Jenneke, Principal Consultant & Practice Lead at Cypher Agency. Keith leads our data platform and AI engineering practice, building on Azure Databricks across professional services, resources, and government.
References
Business Insider, via Yahoo Finance. (2026). Curative CEO says company ditched a $600k-a-year Salesforce contract after vibecoding a CRM in 2 months.
Startup Fortune. (2026). Curative CEO canceled a $600,000 Salesforce contract after vibecoding a replacement CRM in two months.
eMarketer. (2026). Custom AI-coded apps help small firms trim SaaS expenses.
Salesforce Ben. (2026). Salesforce SMB Customers Switch to Vibe-Coded CRMs.
Aquiva. (2026, April 1). Thinking About Replacing Salesforce With Your Own Vibe-Coded CRM? Read This First.
Comments