Everyone is declaring the death of SaaS. Vibe-coded AI apps, the argument goes, will let anyone spin up a custom application in hours. Why pay for software when you can build it?
It’s a compelling argument. It’s also incomplete.
Here’s what people keep missing. SaaS wasn’t just about moving apps to the cloud. That was the delivery mechanism. The real disruption was pricing. Before SaaS, enterprise software came with six-figure license fees, annual maintenance contracts, and implementation costs that could dwarf the software itself. SaaS turned that into a monthly subscription. It democratized access. Small teams could use the same tools as large enterprises. Procurement got simpler. CFOs could actually predict costs.
The pricing model, not the cloud hosting, broke the back of legacy software. The cloud was the vehicle. Affordable, predictable pricing was the weapon.
AI doesn’t just change the delivery. It changes what software is. That’s a bigger shift. But the playbook for how it takes hold? I’ve seen this movie before.
I’ve Seen This Movie Before
I’ve watched this play out a few times in my career. The details change. The pattern doesn’t.
Early in my time at Microsoft, I was a product manager on SQL Server. We weren’t trying to displace Oracle or IBM DB2 on day one. That would have been a losing fight. Instead, we targeted departmental workloads. Small databases, team-level applications, the stuff that didn’t warrant a call to the enterprise vendor. Microsoft Access was the gateway. Cheap, approachable, good enough for a department that needed to manage data without a DBA. Then as those workloads grew, they needed something more serious. SQL Server was the answer. What started on a random server under someone’s desk eventually moved into the data center.
When we shipped SQL Server 7.0, we bundled Analysis Services, a full OLAP and data warehousing tool, for free. Oracle was charging $30,000 per processor for the equivalent. Ours worked natively, and it connected directly to the thousands of Access databases we had already seeded into enterprise departments. The migration path was built in. Customers didn’t need to make a case for it. The decision had already been made, one department at a time.
Oracle and IBM watched this happen. They weren’t wrong that their products were more powerful, more mature, more capable at scale. They were wrong about what mattered in the early innings. They underestimated the beachhead. By the time those departmental SQL Server deployments had grown into enterprise workloads, the conversation had already shifted. The person who bought Access for their team was now the one making the database decision for the whole organization.
I’ve seen the same movie with cloud SaaS displacing on-premise software. Different cast. Same arc.
The CO₂ Problem
CO₂ is odorless. You can’t see it. It doesn’t trigger any alarms. It just accumulates, quietly and steadily, until the environment has already changed around you.
AI-native applications work the same way.
They don’t show up as existential threats. They show up as a solution to one specific problem in one specific team. The champion isn’t the CIO. It’s the product manager who got tired of waiting for the analytics team to build a report. It’s the sales ops person who figured out they could automate their weekly pipeline review. It’s the engineer who replaced three tools with one.
No big procurement process. No executive mandate. Just a problem getting solved, then another, then another. By the time the CIO has full visibility into what’s happened, the CO₂ is already in the room.
This isn’t a security warning. It’s just how technology actually moves through organizations. Not top-down. Bottom-up, one justified use case at a time.
What This Means If You’re Running a SaaS Business
If you spent the last two decades moving a legacy workflow to the cloud, you are not safe simply because you’re cloud-native. That was the bar ten years ago. The bar is higher now.
The real question is whether your product is defensible at the workflow level. Not the category. Not the platform. The specific thing your users actually show up to do every day. Can an AI-native alternative do that faster, cheaper, or with less friction? If yes, you have a timeline problem.
The companies that come through this well won’t be the ones who bolt AI onto existing products and call it a feature. They’ll be the ones who look at their core workflows and ask honestly: if we were building this today, what would it look like? Then they’ll go build that version before someone else does.
Velocity Is Not a Strategy
When Xero launched in 2006, the prevailing wisdom was that being born in the cloud was a decisive advantage. It was. But it wasn’t enough on its own. I know because I was there. As Xero’s first Chief Product Officer, I watched what actually separated Xero from the cloud accounting competitors that didn’t make it. It wasn’t the delivery model. Rod Drury and the team had built something genuinely better. Cloud got us in the door. Product quality and a real obsession with customers kept people there and turned it into a global business.
The same thing played out across the broader SaaS wave. Siebel had 45% of the CRM market in 2002. Four years later it was absorbed into Oracle. The popular story is that Salesforce killed Siebel with SaaS pricing. That’s partly true. But Siebel was already weakened, over-reliant on telecom customers, poor on service, slow to move. Salesforce didn’t just win on model. They won on execution.
That history matters now because the AI conversation is running the exact same script the cloud-first crowd ran twenty years ago. AI-first wins. Ship fast, iterate fast. Velocity is the moat.
I don’t buy it. Velocity gets you to market. Quality keeps you there.
A vibe-coded app that solves one workflow problem in one department is not replacing enterprise systems of record. Shipping a v1 is maybe 2% of the work. The other 98% is security, compliance, integrations, support, reliability and the thousand edge cases that real enterprise usage eventually surfaces. That’s where the game gets won or lost.
The AI-native companies that win will move fast and build something that holds up under pressure. The ones that treat velocity as the whole strategy will hit a wall, usually at their first serious enterprise security review, or the first time something breaks in production with no support structure to catch it.
AI-native is a starting position. Not a finish line.
What This Means If You’re Building AI-Native
The beachhead strategy still works. Find the department with the pain. Nail that workflow completely. Make the internal champion look good. Then expand.
What’s different this time is speed. SaaS disruption took the better part of fifteen years to reshape enterprise software. AI moves faster. The window between beachhead and platform is compressing fast.
That’s good news if you move. It becomes a serious problem if you wait for the market to come to you.
On the Jobs Question
One more thing worth saying directly because it keeps coming up.
AI is not going to take people’s jobs. That framing has been wrong about every major technology shift in history. The PC didn’t eliminate jobs. SaaS didn’t eliminate jobs. They changed jobs, created new ones and removed specific tasks from existing ones.
AI will follow the same pattern. The people who learn to use these tools well, who develop real intuition for where AI helps and where it still falls short, will be more productive, more valuable and harder to replace. The people who ignore it will be at a disadvantage.
AI won’t take your job. But someone using AI might.
That’s the pattern. Departmental beachhead, internal champion, quiet expansion, and then the incumbents wake up to find the environment has already changed.
I’ve seen it happen. It’s happening again. The difference this time is the speed.
Pay attention.