Everyone's talking about the SaaSpocalypse like it's a foregone conclusion. AI gets good enough, building gets cheap enough, and SaaS just kind of... ends. I don't think that's right. But the fact that cost is the language of that argument tells you something important about how we've been making build versus buy decisions all along.
The supply curve shifted and nobody noticed
Most of the conversation around AI centers on disruption in the abstract: will it take my job, will it change my industry. What gets less attention is the economic mechanics underneath it. That's where investors are actually placing their bets. Not on the headlines, but on what happens when a new technology rewrites the cost curve entirely.
Engineering is the clearest example. AI didn't just make developers faster. It removed the barrier to entry to building software entirely. Tools like Cursor, Claude Code, and GitHub Copilot mean you no longer need to be an expert to produce working code. More people can build, which means the effective supply of development capacity has expanded dramatically. Basic economics from there: supply shifts out, demand stays roughly the same, price falls. The cost to build software drops.
The instinct that follows is understandable. If it's cheaper to build, maybe we should build more ourselves. But here's where the logic starts to fold back on itself. It's cheaper for everyone. The SaaS vendors you'd be replacing are running on the same tools, seeing the same cost reductions, and they know the market knows it. That puts downward pressure on SaaS pricing too. So what looked like an argument for building, lower costs, turns out to also be an argument for buying getting cheaper. The cost advantage of building dissolves almost as fast as it appears.
Which means if cost is your primary reason for reconsidering build versus buy, you're solving the wrong problem.
You've been asking the wrong question
So if cost is heading toward zero on both sides of the equation, what's left? This is where the SaaSpocalypse narrative gets interesting, and a little overhyped. SaaS isn't going away. It's going to get cheaper. The vendors will push back, they'll bundle, they'll protect margin in the ways incumbents always do. But the direction of travel on price is down, for building and for buying. Cost stops being the differentiator.
And honestly, it was never a great one to begin with.
Cost became the default lens for build versus buy because it was the easiest thing to defend in a budget meeting. You could put a number on it. You could build a spreadsheet, compare license fees against engineering hours, and walk out with a recommendation that felt rigorous. But that framing always obscured the more important question underneath it.
Because SaaS vendors aren't just selling you a feature. They're selling you the trust that comes from having solved that problem for thousands of customers. The edge cases they've already hit. The compliance requirements they've already navigated. The integrations they've already built. When you buy a SaaS product you're not just buying software. You're buying the expertise of an organization that has made that problem their entire focus. That doesn't show up when you're comparing features on a spreadsheet.
Which means the real question was never "can we afford to build this." It was always "should we own this problem." Those are very different questions. One is about budget. The other is about where you want your organization's attention, capability, and identity to live. AI just stripped away the cost variable that was letting everyone avoid having that conversation.
Shipping is the easy part
Say a mid-size company decides to build their own onboarding tool. The SaaS options felt bloated, the price was hard to justify, and one of the engineers had a free sprint. So they built it. It worked great.
Six months later HR wants a new field added. Three months after that compliance needs an audit trail. Then someone asks why it doesn't integrate with the new HRIS they just bought. Now there's a Slack channel dedicated to onboarding tool bugs. One engineer has become the de facto owner, which means when she goes on vacation nothing gets fixed. The tool isn't on any roadmap because it was never supposed to be a product. But it's not going away either, because three hundred employees move through it every quarter.
Two years in, nobody remembers it as a scrappy internal build. It's just "the onboarding system." It has a backlog. It has stakeholders. It has opinions. And somewhere along the way the question of whether you should have built it stopped being answerable, because the cost of unwinding it is now higher than the cost of maintaining it forever.
Does that touch a nerve? Good. Because that's one tool. Now imagine that decision gets made a dozen times across the organization. Each one with its own stack, its own quirks, its own context that someone needs to hold in their head. Your engineers are context switching between totally different codebases, trying to understand use cases that are each unique, debugging problems in systems they didn't build and can't fully map. The cognitive overhead alone is brutal.
And then there's everything else. Governance. Process. On-call rotations. Documentation. All of the things that have to exist around software to keep it healthy. None of that shows up in the build cost estimate either.
This is what owning a problem actually means. Not shipping code. Building the muscle, the process, and the people to actually maintain it. That's a real commitment and it has real value when it's aligned with where your company is going. But when it isn't, you've traded a SaaS bill for something far more expensive and far harder to unwind.
The strategy question isn't just should we build this. It's are we prepared to own this, and does owning it make us better at what we're actually trying to do.
This is where it gets uncomfortable
Here's what's actually happening in most boardrooms right now. Engineering leaders are walking in saying costs are dropping, we can build faster than ever. Boards are hearing that and responding the way boards do: go, go faster, do more, implement everything. Every new AI release triggers a reaction. When Anthropic released a legal plugin for Claude Cowork in February 2026, $285 billion in market cap evaporated from legal tech and software stocks in a single day. Thomson Reuters dropped 16%. LegalZoom nearly 20%. The "product" that caused it was a text file on GitHub, a set of prompt instructions, not a new model, not a new API. That's not disruption playing out. That's a market reacting to a headline before anyone asked whether the threat was real. The pressure to move is coming from the top, and it's outpacing the thinking.
Source: Anthropic AI Tool Sparks Selloff From Software to Broader Market — Bloomberg, February 4, 2026
And somewhere in that organization, someone has to be the one to stand up and say: yes, we could build this. But should we?
That takes guts. Because you're not just pushing back on an idea, you're pushing back on momentum. On board pressure. On the very real fear that your competitors are moving faster than you. The person who plays that role, who has the strategic clarity and the confidence to say we're being intentional about what we own, is doing some of the most important and underappreciated work in the organization. Careers get made on that kind of judgment. They also get questioned in the moment, because it looks like slowness when everyone else is sprinting.
But doing that well requires actually knowing where you're going. Not just having a roadmap on a slide somewhere. A vision that's real, socialized, understood across the organization. Most companies think they have that. Fewer actually do. And cost was the red herring that let everyone avoid finding out.
What's coming if that work doesn't happen is predictable. We've seen this movie before. When Power BI democratized data, suddenly everyone could build a report. And they did. The result was a sprawling mess of competing dashboards, conflicting numbers, no single source of truth, and a wave of governance initiatives to clean it all up. That cleanup was expensive, slow, and largely avoidable.
The same wave is coming for bespoke software. The organizations that get ahead of it won't be the ones who moved fastest. They'll be the ones who were strategic about what they chose to own, and disciplined enough to say no to everything else.