There’s a thesis circulating in tech circles (mostly among practitioners), that AI is going to gut a meaningful slice of the SaaS industry, creating an industry shifting “SaaS-pocalypse”.
The argument runs roughly as follows:
- A product team with context engineering capability, AI coding agents, and a structured corpus of its own data can now ship in weeks what enterprise software vendors used to spend years productizing.
- The build side of the "build-vs-buy" equation collapsed; the buy side got more expensive as incumbents wrap their legacy platforms in language model veneers and charge thirty percent more for them, while the cost to develop has plummeted.
- The conclusion is that the era of buying your capability is ending, replaced by an era of building it.
I largely subscribe to this thesis. I run a portfolio of non-consumer revenue businesses, and I watch internal product teams ship things every week that would have taken vendor RFPs, evaluations, contracts, and implementations the better part of a year to deliver. The economics moved. Most leadership teams haven’t priced it in yet.
The Steelman Counter
A high-profile SaaS CEO recently went on a podcast and laid out the most rigorous counter-argument to this thesis I’ve seen anywhere. His position is worth taking seriously, both because it’s the version of the case I’d want my own preferred incumbents to make, and because most of the other defenses I’ve read are sentimental rather than logical.
His argument runs in three moves:
- COST: First, the idea of replacing a workflow platform with a raw language model is roughly ten times more expensive than the current implementation and produces worse outcomes, because workflow platforms are deterministic and language models are probabilistic.
- SOR: Second, the orchestration layer between hyperscalers, language models, and “systems of record” (SORs) captures more value than any of the things it connects, because enterprises require accountability they can attach to a vendor.
- DATA: Third, the platform “knows your business” in a way no language model can, because the platform has been loaded with your workflows, approval chains, and SLAs. Volume becomes the moat. Tens of billions of workflows, and trillions of transactions.
He closes with a leadership flourish about being fully dressed when the tide goes out.
It’s a polished case, but it's also a strawman dressed in a suit.
Why the Argument Falls Apart
Nobody serious is proposing that companies fire their workflow platform and ask a frontier model to manage all of their workflows. That’s not the trade.
The trade is whether an internal product team, equipped with context engineering, AI tooling, and proximity to actual business logic, can outbuild the customer-facing innovation of an entrenched vendor whose roadmap is gated by quarterly earnings and the gravity of a billion-dollar install base.
That isn’t a 10X cost problem. It’s a positioning problem, and the CEO either misses it, dismisses it… or secretly fears it.
What “Knowing Your Business” Actually Means
Start with the “knows your business” claim, which is the part of the steelman that sounds most plausible until you press on it.
What the vendor actually means is that after a multi-million dollar implementation, after months of data migration, after your team has manually loaded every workflow and SLA into their schema, then the platform “knows” your business.
The platform is a container that stores what you told it. Calling that “intelligence” is a misnomer. The platform doesn’t “know” anything; it has been told. As actual learning systems get cheaper to build, that category error becomes more conspicuous every quarter.
The vendor’s preferred answer to this critique is integration. More connectors, more MCP servers, more retrieval endpoints (and more integration consultants). Point the agentic layer at Jira, Drive, Confluence, Slack, the wiki nobody updates, the deck from Q2, the ADR that contradicts the production code. Let it stitch the corpus together at runtime. This works once before it deteriorates: scavenger hunts across non-authoritative sources, runtime reconstructions that derive the world slightly differently on each call, drift degradation where the agent acts on stale documents it has no mechanism for recognizing as stale. The proposed remedy, in every case, is more connectors. That’s the SaaS incumbent’s preferred future. Sell more integrations, become the orchestration layer, charge for the privilege of stitching systems they don’t own to models they don’t train. It’s a clean revenue line. It also has approximately nothing to do with whether the resulting system gets smarter. I write more about this in the case for building over configuring.
The Build Math Flipped
This is the structural mover underneath all of it. For the past 15-20 years buying was the rational default because building was actually expensive and slow, vendors had legitimate scale advantages, and the cost of integration was lower than the cost of bespoke engineering. None of those conditions hold the way they used to.
A capable product team with the right tooling can ship purpose-fit systems in a fraction of the time and cost it used to take. Meanwhile the buy-side cost is going up, not because vendors got dramatically better, but because their “AI transformation” pricing assumes the customer can’t tell the difference between real architectural change and a language model wrapper retrofitted onto a legacy codebase.
The Argument Is Political
The argument that follows from this isn’t really about technology. It’s about who in a large company gets to set technology strategy.
IT procurement has, for fifteen years, won almost every internal build-versus-buy debate because the math favored buyers. Procurement is a trained buying muscle: evaluate, RFP, license, manage. Product organizations are trained building muscle: prototype, ship, iterate.
The buyer’s organization wins when buying is rational. The buyer’s organization keeps winning, by inertia, well past the point where buying stops being rational. The CEO’s podcast appearance was a pitch to that buyer.
Thirty-day go-lives, control towers, tens of billions of workflows. That language is calibrated for the CIO who needs a vendor to point at when something breaks. The VP of Product two floors up is in a different conversation entirely.
What I Actually Do
I don’t have a tidy framework to close this with, just the practitioner algorithm I actually use.
- Default to building when the system of record is the differentiator, because the vendor’s data model will become your business model whether you wanted that or not.
- Default to buying when the system is undifferentiated infrastructure (SSO, payroll, observability) where the vendor’s scale really does beat anything internal.
- Apply real pressure to the contested middle (workflow, CRM, marketing operations, support) where the build math actually moved and where most enterprise software now lives. Discount, sharply, any “AI transformation” pitch from a vendor whose share price depends on protecting a legacy revenue line.
Hire builders, not buyers, into the seats that allocate the budget, because the org chart will keep buying long after the math says build.
Where This Lands
The SaaS-pocalypse isn’t language models replacing workflow platforms. That was always a strawman. The SaaS-pocalypse is internal product teams who no longer need the platform at all, in a meaningful and growing slice of the contested middle.
The incumbents who survive will be the ones who actually cross over into adaptive, learning architectures.
The rest will discover that their real moat was never the technology. It was the buyer’s organization. And the buyer’s organization is the thing that just got disrupted.
The era of buying your way into capability is ending. The era of building your way into context has started.
