Build.
The build vs. buy math has changed. Most organizations haven't caught up.
The build versus buy question has been around as long as enterprise software itself. For decades, the answer veered heavily toward the “buy” camp. This wasn’t because buying was always better, but because building was hard and had some risk. You needed specialists, you needed time, and time had a way of slipping. You needed budget that procurement could justify, teams that understood the languages and the stack, and someone to maintain what you built after the team moved on. This calculus leaned toward vendors almost by default.
That calculus has changed. I’ve been working in AI and machine learning systems long enough to have watched several of these inflection moments arrive and then take longer than expected to actually reshape how organizations operate. This one feels different. The constraint that always anchored the build side of that equation — the need for developers with specific expertise in specific stacks and languages — is gone. And when that constraint goes, the math shifts in ways that go well beyond what the current conversation is capturing.
Most organizations are still navigating by the old position. Dead reckoning works until conditions change. The conditions have changed.
Dead Reckoning
My recommendation, stated plainly: build.
Not everything — there are categories where buying still makes obvious sense, and I’ll get to those. But for the layer of workflow tooling, internal automation, and operational software that sits between your core infrastructure and your people, the default answer has flipped. The organizations that figure this out first will have a structural advantage over those that don’t.
If your current approach is to buy a generic SaaS tool, adapt your workflows around it, log support tickets for the 30% it doesn’t cover, and wait eighteen months for a vendor roadmap that may never address your actual problem — you are going to look a lot like every other organization that made the same choice. That’s the buy path now: same tools, same constraints, same gaps, same workarounds as your competitors. The build path, with AI-assisted development, is where differentiation lives. The question worth asking is whether you want to be first to recognize that or last.
The Old Math
The traditional build versus buy framework was a proxy for cost and risk.
Building software was expensive because it required rare, specialized talent. A backend developer who knew your legacy ERP’s API was not the same person as the one who understood your data warehouse, who was not the same person who could build a usable frontend, who was not the same person who could wire up the integration layer. Every specialization had a price, a wait, and a probability of going sideways.
So organizations bought. SaaS vendors emerged to serve exactly this gap and charged you a monthly seat fee for access. The logic made sense to many. You got a working tool without the overhead of building one, and you were paying for the vendor’s accumulated expertise in that problem domain. For most enterprise software over the past twenty years, buying was the right answer most of the time, and the industry grew enormous on the back of that reality.
What changed is not that software got simpler. The problems are as complex as ever. What changed is how we engage with that complexity.
The Specialist Constraint Is Gone, Out the Door
I’ve been doing AI-assisted development long enough now to say this with confidence: the specialization barrier has come down. A developer who works primarily in Python can now build credibly in TypeScript. Someone who has spent years on backend systems can build a functional, production-grade frontend. An engineer who has never touched a particular framework can get productive in it at a pace that would have been implausible two years ago.
I watched this play out directly not long ago. A firm pitched a large Salesforce implementation to a client. They spent significant time explaining why they needed more Salesforce specialists — why the engagement required dedicated platform expertise that was hard to find and expensive to retain.
The specialist argument is gone. What’s worth saying is that buying into large SaaS platforms and ecosystems created a lot of its own risk — it bred a class of “over-specialists” whose entire value was platform-specific. That dependency was baked in by design. A capable development team with AI tools can cover ground that previously required years of platform-specific experience to walk.
This is what gets lost in the broader “AI makes developers faster” conversation. The productivity gains are real and well-documented — GitHub’s research puts task completion rates 55% faster in controlled settings, and Anthropic’s own internal data shows a 67% increase in merged pull requests per engineer per day after Claude Code adoption. Those numbers matter.
In my own work, I’ve seen productivity multiples that make those figures look conservative — closer to 700% in some cases, depending on the task and the tooling. The controlled study numbers are a floor, not a ceiling.
But — the more consequential shift is not speed within a domain, it’s the collapse of the boundary between domains. “Collapse” may even be too soft of a word here. Anthropic’s internal study of their own engineering teams found backend engineers successfully building complex UIs, security teams analyzing unfamiliar codebases, researchers building their own data visualization tooling. The “generalist” developer, I’d argue the real developers, are becoming much more appreciated, and it’s high time.
The traditional answer was often “we have to buy because we don’t have anyone who can build this.” That answer is no longer reliable as a constraint.
What the Data Shows
Retool’s 2026 build versus buy report, drawn from 817 enterprise builders surveyed in late 2025, found that 35% of enterprise teams had already replaced at least one SaaS tool with a custom build, and 78% expected to build more internal tools over the coming year. These are not small experimental teams at software companies. These are operations, finance, IT, and product teams at organizations ranging from startups to Fortune 500s.
What’s driving this is not ideological. It’s economics and fit. A significant portion of enterprise SaaS spend goes toward tools that solve a generic version of a problem, when the actual problem the organization has is slightly different — different enough that the SaaS solution requires workarounds, exports to spreadsheets, manual handoffs, and a support ticket backlog that stretches for months. Organizations pay for the tool, they pay for the seats, and then they pay again in productivity overhead for the gap between what the tool does and what they actually need.
The Retool data shows that workflow automation, internal admin tools, and BI and analytics tools are the first categories where the replacement behavior is showing up, and that makes sense. These are the categories where the generic SaaS solution is thin enough that building a custom version with AI assistance is now a reasonable project for a motivated team, and where the gap between what the tool does and what the team needs tends to be widest.
Hidden Costs We Don’t Track
There’s a second layer here that I think gets underappreciated, and it’s one I’ve seen play out across enterprise deployments for years. When an organization buys a SaaS tool and that tool doesn’t quite fit, the cost doesn’t disappear. It moves. It moves into support tickets, into workarounds, into features requested of the vendor that sit in a backlog for eighteen months, into manual processes that exist because the integration doesn’t quite work, into shadow systems that spring up around the edges of the official tool to handle the cases it can’t.
These costs are genuinely hard to trace. Root cause analysis on why a workflow is slow or why a process keeps failing rarely points cleanly to “we bought a tool that doesn’t fit.” It tends to surface as operational friction, as team inefficiency, even morale problems around systems people find frustrating to use. The cost is real, it’s significant, and it almost never shows up in the line item next to the SaaS subscription that caused it. Companies talked about technical debt, but they never talked about architectural or tool debt.
What AI-assisted development does, in addition to lowering the cost of building, is make it possible to build something that actually fits the workflow — not a generic solution that the team adapts around, but a tool shaped around how the process actually operates. The productivity gain from fit is harder to measure than the productivity gain from speed, but I’d argue it’s larger over the long run, and it’s the kind of gain that also makes the underlying operational problems visible rather than hiding them in workaround behaviors.
The Market Has Priced This In
The broader enterprise software market has felt this in a way that is hard to ignore. By early 2026, the sector had shed roughly $285 billion in market capitalization as AI-driven seat compression started to show up in vendor revenue projections. Salesforce saw its stock fall approximately 40% from its 2025 highs. Workday dropped more than 20% in a single month. The mechanism here is slightly different from the build-versus-buy substitution I’ve been describing — seat compression is driven more by AI agents doing the work that previously required human users than by organizations building replacement tools — but both effects are moving in the same direction. The assumption that enterprise software spending would grow with headcount, that more users meant more seats meant more revenue, is breaking down from multiple directions simultaneously.
The SaaS vendors who are most exposed are the ones in categories where the problem is generic enough that AI-assisted development makes substitution plausible, the fit gap is wide enough that users are frustrated, and the switching cost is low enough that an aggressive team can move. Vendors in categories with deep compliance requirements, genuine vertical complexity, or strong network effects that are actually being used are in a more defensible position. The pressure lands first on the tools that were already thin on value.
What This Means in Practice
I don’t think this means organizations should stop buying software. The custom build question is still a real question, and buying is still the right answer in many cases. What’s changed is that “we can’t build this” needs to be re-examined as a default assumption. The honest version of that question now is: could we build a version of this that fits us better, at a cost that makes sense, with the team we have and the tools now available to us?
For many organizations, the answer to that question is going to be different than it was two years ago. Not for everything, not for the complex infrastructure that genuinely requires deep specialization to build and maintain safely, but for the layer of workflow tooling, internal automation, and operational software that currently exists because someone once decided the build cost was too high — that layer deserves a fresh look.
The SaaS subscription that covers 70% of the need while the team builds workarounds for the other 30% is a cost structure that increasingly has an alternative. The backlog of requested features that never gets addressed is a debt that can now be retired. The structural assumptions that made buying the obvious answer are no longer as structural as they were, and the organizations that recognize that early will have a real advantage over those still navigating by an outdated position.
Let me know what you’re seeing in your own build versus buy decisions. I’m curious how widely this is resonating at the enterprise level.