SaaS PE Is Dead, Long Live SaaS PE! (Part 1 of 2): What AI Actually Killed
The people making this argument aren't fools. It goes like this.
Software as a service was a bet on a specific asymmetry: building was expensive, buying was cheap, and so a company with a working product and a renewal rate could compound quietly for a decade. Private equity understood that bet better than almost anyone. Recurring revenue, high gross margins, switching costs that made churn a rounding error. You could underwrite that. You could put debt on it.
Then the cost of building software fell through the floor.
If you believe that the asymmetry is gone, everything downstream of it goes too. The renewal is no longer safe, because your customer can now build the thing. The pricing power is no longer real, because eleven competitors launched into your category this quarter. And the multiple you paid (the one that assumed both of those things would hold for five more years) was a mistake you've already made and can't unwind.
I want to take all of that seriously before I take it apart.
The case for the funeral
It rests on three legs, and two of them hold.
Build has stopped being expensive. The single-workflow tool, the one that solved one annoyance well enough to charge forty dollars a seat for, was always living on borrowed time. What protected it wasn't brilliance but friction: someone would have had to staff a project, scope it, hire for it, maintain it. That friction is mostly gone for this class of software. An engineering team can now own the thing outright, shape it to how they work, and stop paying rent on it. If your product is a form, a queue, and a report, the conversation about replacing you is now a short one.
The glut is real. Generative tooling has made it possible to ship a plausible version of almost anything into almost any category with a visible margin. Not a good version, necessarily, but a plausible one: a landing page, a demo that works, a pricing tier, a security page with the right words on it. When a hundred of those exist in a category, differentiation stops being visible from the outside. And when differentiation isn't visible, price is the only axis left, which is a race everybody loses except the buyer.
And so the multiple compresses. This one is a private equity problem more than a product problem. Retention and pricing power were the two variables underwriting the entry price. If both are impaired, the value was destroyed at the moment of purchase; the operator just hasn't been told yet. Funds that bought thin SaaS at 2021 multiples are going to spend the next several years discovering this one portfolio company at a time.
The mechanics are unforgiving. A five-year hold assumes you exit into a market that still believes what you believed at entry. Leverage assumes cash flows you can forecast. Both assumptions were reasonable in a world where a competitor needed eighteen months and a Series A to become a nuisance. Neither survives a world where a competent team ships a credible alternative in a quarter. And the fund can't wait it out. The clock is contractual; the hold period doesn't extend just because the thesis got harder.
If you own that kind of software, or you paid that kind of multiple for it, the funeral isn't premature. You're late to it.
What the funeral gets right
I'm not going to defend the corpse.
Thin-wrapper SaaS is in real trouble. So is single-workflow software with low switching costs, and so is anything whose moat was that building it was annoying. If your product can be described completely in one sentence, and that sentence doesn't contain a regulator, an auditor, an integration that took eighteen months, or a consequence for getting it wrong, then the asymmetry that protected you is gone and it isn't coming back.
Some of these companies will be fine, because they're cheap enough and good enough and switching is a hassle. Most of them will slowly stop growing, which in this asset class is the same thing as dying, just with a longer tail and a worse board meeting.
I'm not conceding this as a rhetorical move. Without the concession, the rest of the argument means nothing. Someone who defends every category isn't analyzing, they're selling.
The concession that costs something
This is where people in my line of work usually stop conceding, and where it starts getting interesting.
The obvious counter to everything above is: fine, but regulated software is different; you can't vibe-code your way into a SOC 2. I've spent fifteen years building security and compliance programs inside a payments platform, and I'd love for that to be true.
It isn't. Or at least not in the way people mean it.
AI will write your policies, and it will write them well, better than the templated ones I've reviewed from companies with real revenue. It drafts control narratives, maps controls across frameworks, generates a risk register, and assembles evidence far faster than the analyst who used to do it by hand. The system description it produces reads just like the ones that pass.
I say that with some confidence, because a meaningful part of my job over the past decade has been reading other companies' security documentation (vendor questionnaires, SOC 2 reports, policy sets, architecture descriptions) and deciding what to believe. The tell was never prose quality. Bad actors and good ones both had documents. The tell was whether the document described something the company was actually doing, and you found that out by asking a second question the document hadn't anticipated. What's changed is that the documents are now uniformly excellent. The first question tells you nothing at all.
And with a cooperative enough auditor, it will probably walk a shell of a company to a clean report. Audit quality isn't uniform, and never has been. There are firms that will test what you tell them to test, and there are always going to be buyers who see the logo on the front page of the report and stop reading.
So the honest position is this: the SOC 2 report, considered as a document, is a depreciating asset. The artifact is being commoditized right now, along with everything else that's a writing task. If your compliance function's product is paperwork, your compliance function has the same problem as the single-workflow SaaS company.
The turn
Now hold both of those at once, because the second doesn't rescue the first. It detonates it.
When every vendor can manufacture surface credibility, surface credibility stops being worth anything.
Not a small adjustment. The ground is moving under the whole category. For twenty years the entire apparatus of enterprise software buying has run on cheap proxies: the report, the questionnaire, the trust page, the logo wall, the certification badge in the footer. Those proxies worked because producing them was expensive enough to be a signal. Producing them is no longer expensive. So they aren't signals anymore. They're table stakes, which is a polite way of saying noise.
A buyer facing a hundred plausible vendors, all of whom have the badge, can't discriminate cheaply anymore. And a buyer who can't discriminate cheaply does one of two things. They either stop discriminating, which is how you end up with a breach and a lawsuit, or they fall back on the signals that are still expensive to fake.
Here the funeral gets it wrong. The glut isn't a threat to a durable platform. It's what makes the difference visible again, because it destroys the cheap signals that used to let a newcomer stand next to it and look roughly the same. For years, being twelve years old and boring and thoroughly assessed bought you nothing you could point at. The startup had the same badge on their site. Now the badge is meaningless and the twelve years are the only thing left in the room.
Scarcity moved from the artifact to the proof.
What can't be generated
So what's still expensive? Four things, roughly in order of how hard they're to fake.
Operating history under real conditions. Not uptime; anyone can claim uptime. I mean: something went wrong, and there's a record of what you did. An incident, a postmortem, a customer notified on a bad Tuesday, a control that failed and got rebuilt. Every mature platform has this scar tissue and every young one is missing it, not because the young team is careless but because they haven't had their bad week yet. You cannot generate a history of surviving things. You can only accumulate one.
This is also the least forgeable thing in a data room, because it's corroborated by people outside the company. Incidents leave fingerprints elsewhere: in a customer's vendor file, in an assessor's working papers, in a notification that went out on a specific date. A platform that claims a clean decade and has no external trace of ever having handled anything isn't reassuring. Either they're very young, or they aren't telling you the truth.
A named accountable human. Somebody whose signature is on the control environment and whose professional reputation is attached to it being true. This is the part of due diligence people skip because it feels like a formality, and it's the least skippable thing on the list. Ask who owns security. Ask how long they've been there. Ask what they owned before. A platform where that person has been in the seat for years, has survived assessments, and can explain the reasoning behind a control rather than reciting it, is a different asset entirely from one where the answer is a fractional contractor and a tool subscription.
The distinction shows up fastest under pressure. Anyone can read a control back to you. Far fewer people can tell you why the control is designed the way it is, what it traded away, what broke the last time it was tuned, and which compensating control is carrying the weight when it fails. That isn't knowledge you can transfer in an onboarding doc, and it isn't knowledge a model can supply, because it was never written down anywhere.
Customers who audited you and stayed. This is the underrated one. When a large enterprise customer runs a real security review (the months-long kind, with their own assessors, their own questionnaire, their own lawyers) that's a third party spending their own money to verify you, and then continuing to pay you afterward. You can't buy that and you can't generate it. It compounds, because each one makes the next one easier, and it's visible in a way that no self-attestation ever is.
Having sat on the receiving end of a great many of these, I can tell you the questionnaire is the least interesting part. The part that separates companies is the follow-up: the assessor who doesn't accept the policy as evidence and asks to watch the process run, who wants the ticket history rather than the procedure document, who asks what happens when the person named in the runbook is on leave. Surviving that isn't a documentation exercise. Nothing you can generate gets you through it, because the questions are generated in response to your answers.
Time-denominated relationships. Acquirers, regulators, assessors, and the payment brands know some companies and don't know others. Being known isn't a favor and it isn't a shortcut past anything; it's the accumulated result of years of showing up with your work in order. It can't be bought and it can't be accelerated, which is what makes it worth something.
In payments this is especially stark, because the assessment cycle never really ends. A Level 1 program isn't a certificate you collect; it's an annual obligation with a standard underneath it that keeps moving, and every migration to a new version of that standard is a fresh opportunity to be found wanting. Companies that have been through several of those cycles have something a new entrant can't have yet, no matter how good their tooling is: a track record with the people who will be assessing them again next year.
None of these are documents, which is the whole point. Every one of them is a fact about the world that took years to become true.
The thing nobody prices: people who already know how to use it
There's one more, and it gets left out of every build-versus-buy conversation I've ever sat in.
Nobody arrives already knowing your in-house tool.
You can hire someone with a major commercial platform on their résumé tomorrow. There's a labor market for it: people who have administered it, integrated it, migrated onto it, broken it and fixed it somewhere else on someone else's payroll. There are certifications, forums, consultants, contractors, a decade of Stack Overflow answers, and a stack of documentation written by people whose full-time job was writing it.
For the thing you built yourself, the talent pool is exactly the people who built it. Not a talent pool. Key-person risk with a nicer name. When the engineer who designed your internal replacement takes another job, they don't leave behind a market of qualified successors, just a repository and whatever made it into the wiki.
The build case almost always prices construction and quietly ignores everything after it. It compares a license fee against a sprint estimate, when the real comparison is a license fee against a sprint estimate plus permanent ownership of onboarding, documentation, institutional memory, and the day your only expert resigns.
And here's the 2026 version, which I think is underappreciated: the models already know the incumbent platforms. They were trained on a decade of public documentation, forum threads, integration guides, and community code for every major commercial system. Ask about one and you get a competent answer. They know nothing about the thing you generated last quarter. No training data exists, because it has only ever existed inside your repository.
So the same technology that made building look cheap is dramatically more useful to you when operating a long-lived commercial platform than when maintaining the bespoke tool it just talked you into. The build case borrowed AI's leverage to argue for construction, and then handed you the one artifact AI can't help you run.
None of which tells you what to actually check.
If the cheap signals are noise, and the durable signals are things like operating history and accountable ownership and customers who verified you, those are harder to see from outside than a badge in a footer. They don't fit in a questionnaire. They aren't in the data room.
They are findable. There's a specific set of things a serious buyer tests, and a specific set of answers that a hastily assembled platform can't produce no matter how good its documentation looks. Part 2 goes after them.