SaaS replacement pipeline is something that's been building for a while: executives are looking at their SaaS bill, looking at what Claude and Codex can scaffold in an afternoon, and asking why they're still paying for it. Klarna shut down Salesforce and Workday in favor of internal tools, and its CEO has talked publicly about why on the 20VC podcast. A Retool survey cited in the piece found 35% of companies have already replaced at least one SaaS product, and 78% plan to replace more in 2026.
I've spend good part of my career as a Salesforce and AWS architect, so I read that Klarna detail differently than most people probably do. Salesforce isn't just "a SaaS tool" to replace, under the hood it also has a complex often monstrous data model, a security model, and years of business logic wrapped around both. When a CTO says "we're getting rid of Salesforce" in an all-hands, it takes about five seconds to say. However,it takes a lot longer to actually do, and the CTO isn't the one doing it, IT developers, testers, BAs and architect are. And the part that gets glossed over in most of this coverage is that building the replacement was never the hard part.
SaaS pricing has always had one built-in defense: building it yourself was expensive and slow. A CRM, a docs tool, an internal dashboard, these used to represent months of engineering time that most companies couldn't justify pulling off their roadmap. That excuse is gone, or at has become at least a lot weaker than it used to be.
Take the Warp example from the LeadDev piece: their team rebuilt their whole documentation tool in two days and ended up with something that fit their brand better than the GitBook subscription they'd been paying for. Two days. That's not some one-off flex, it's basically the new baseline for "can we just build this ourselves." Once a working prototype costs an afternoon instead of a quarter, the renewal math changes, even for vendors who never did anything wrong.
That's a real shift and I don't think it reverses. But "we can build a prototype fast" and "we can replace a system of record" are two very different claims, and the gap between them is where most of these projects actually live or die.
Here's what the coverage keeps circling back to, and what matches what I see in actual Salesforce migrations: the UI was never the constraint. Data extraction is. Klarna's own CEO admitted the switching cost of data was one of the hardest parts of leaving Salesforce, because your proprietary information is sitting inside someone else's data model, not yours.
This is the part that's easy to underestimate if you haven't lived inside an enterprise data model. A Salesforce org isn't just records in tables. It's custom objects with dependency chains, validation rules, flows that fire on specific field changes, sharing rules that determine who can even see a record, and years of undocumented business logic that some departed admin encoded into a workflow rule in 2019. You can export the data with an API call. You cannot export the meaning of that data, or the rules that governed how it got there, without someone doing real archaeology first.
I wrote about inheriting a messy Salesforce org a while back, and the same discipline applies here in reverse: before you plan an exit, you need to actually understand what's load-bearing in the system you're leaving. Vendors know this. It's a big part of why switching costs stay high even after the build cost collapses.
There's a second cost that shows up after the migration, not before it. Felix Godbout's warning in the LeadDev piece is worth sitting with: people are finding "SaaS on GitHub", open-source clones of commercial tools, and standing them up internally without the vetting that comes with a real vendor relationship. No SOC 2, no third-party pen testing, no dedicated security team patching CVEs on your behalf. You inherited the vendor's job without the vendor's headcount.
This tracks with what I've seen on the Salesforce security side too: attackers move fast toward whatever's newly exposed and under-configured. A hastily built internal replacement, especially one that touches customer or financial data, is exactly that kind of target. When something breaks in a SaaS product, you open a support ticket. When something breaks in the tool your team built last quarter, you're the support ticket.
None of this means "don't build it." Plenty of SaaS replacements are the right call, especially for narrow, well-understood workflows like Warp's docs example. But the decision needs a different shape than "can we prototype this faster than we can negotiate a renewal."
A few things I'd actually check before signing up to replace a system of record:
The C-suite's cost pressure on SaaS is real and it isn't going away. AI made the build side of that equation genuinely cheaper. What it didn't do is make the data model, the compliance surface, or the on-call rotation any smaller. Developers are the ones standing at that gap right now, and the teams that treat data portability as a day-one requirement, not a migration afterthought, are the ones who'll actually come out ahead of this.
Burning tokens isn't a productivity metric, it's a cost center. Here's how the frugal AI shift translates into concrete architecture decisions on Salesforce projects.
Hooks let you enforce behavior in Claude Code instead of hoping the model does the right thing. The mental model, three Salesforce-specific hooks, and why this matters more in Salesforce than in most stacks.
If your architecture only lives inside the Salesforce landscape, your role is shrinking. Here is why modern architects must master enterprise patterns outside the CRM sandbox.