Why three of my clients replaced their SaaS tools this year
Three separate clients asked me to replace their SaaS tools this year. Same story each time. The math has shifted, and most product companies don't have an answer for it.
Three different clients. Three different industries. Three different problems.
Same decision.
Replace the SaaS tool we've been paying for. Build our own.
When the first client said it, I thought it was a cost-cutting move. When the second one said it, I started paying attention. When the third one said it, I started thinking about what it actually means for the companies selling those tools.
The Numbers That Started This
Let me give you a concrete example without getting into anything confidential.
Take a typical enterprise document processing platform. The kind that handles invoice extraction, receipt processing, purchase orders. A solid tool, well-built, been around for years. Enterprise pricing sits somewhere between $30,000 and $45,000 a year.
Here is what that tool offers:
- OCR and text extraction across 40+ file formats
- Pre-built templates for 200+ document types
- Human-in-the-loop review workflows
- Multi-language support
- ERP integrations with SAP, Oracle, NetSuite, QuickBooks, and Xero
- Cloud sync with SharePoint, Google Drive, and Dropbox
- Compliance audit trails
- Analytics dashboard
- Role-based access control
- API access
- Mobile app
- Dedicated support tier
Twelve features. Solid product. Genuinely useful.
Here is what my client actually needed:
- Upload a PDF invoice
- Extract six specific fields: vendor name, invoice number, date, line items, total, tax
- Export that data to their internal system
That is it. Two of the twelve features, generously counting. They were paying $38,000 a year for a tool that they used at roughly fifteen percent of its capacity.
So I built them a replacement. It took three months. It cost them $15,000 in development fees. It does exactly what they need, nothing more, and it plugs directly into their existing stack. They break even in the first year. From year two onward, they save $38,000 every single year.
That is not a marginal improvement. That is a different calculation entirely.
What Changed
This conversation used to go the other way.
Three years ago, "build your own" was the expensive option. You needed a team, you needed time, you needed ongoing maintenance, and you were reinventing something that already existed and worked. The $38,000 tool was often the cheaper choice when you added up what a custom build would actually cost.
AI changed that math in two ways.
First, the cost to build dropped significantly. Tasks that used to require senior engineering hours and complex configuration now take a fraction of the time. My invoice client's old tool needed templates configured per document type, each one requiring manual setup and testing. The AI-powered replacement needs no configuration at all. You hand it a PDF and tell it what you want. It figures out the rest, including reading invoices that are scanned images rather than clean PDFs, which the old tool handled poorly at best.
Second, the output quality on targeted tasks got better. Not across the board. AI is not universally better than purpose-built software. But for extracting specific structured data from unstructured documents, it does that one thing more accurately than a template-matching system that was configured two years ago by someone who no longer works at the company.
The Feature Bloat Problem
The document processing example is not unique. The same logic applies across most horizontal SaaS categories.
Enterprise software tends to grow features over time because features justify renewals. Every year, the product team ships something new, the sales team highlights it in the renewal conversation, and the customer stays because switching costs are high and the tool mostly works. The result, after ten years of this, is a platform with thirty features and a customer base where most companies are actively using four or five of them.
That was a defensible position when switching meant a painful and expensive rebuild.
It is less defensible when switching means a focused three-month build that does exactly what you need and nothing you don't.
The question enterprise clients are now asking is not "should we switch to a competitor?" It is "why are we buying software at all?"
The Data Problem Nobody Talks About
There is a second reason clients are building internally, and it has nothing to do with cost.
When you use a third-party SaaS tool for document processing, you are sending your documents to their cloud. For a lot of companies, that is fine. For companies handling sensitive supplier contracts, financial data, customer records, or anything that touches legal or compliance requirements, it is a serious problem.
When you build internally, the data never leaves your environment. The AI model can run against your own documents, in your own infrastructure, with your own context. You are not training someone else's model on your business data. You are not subject to their data retention policies or their breach notification timeline.
This came up with my event management client as well. Their attendee data, payment records, and ticketing information sit in their own database, on their own servers, under their own control. That was not possible with the third-party event platform they were looking at. It was a hard requirement, not a preference.
For regulated industries, this consideration alone closes the debate before the cost conversation even starts.
What This Means for SaaS Companies
The product companies I have spoken to are aware that something is shifting. The smart ones are asking the right question: why should a customer keep paying us when they could build something themselves?
Most of the answers I have heard back are not convincing.
"We have more features" is not an answer when the customer is only using two of them.
"We have years of domain expertise baked in" is a better answer, but it only holds if that expertise is genuinely irreplaceable and not something an AI-powered custom build can replicate in a few months.
"We integrated AI into our product too" is the most common answer right now, and it is the weakest one. Adding an AI layer on top of a bloated, overpriced product does not fix the underlying problem. It just makes the bloated product slightly more capable while the price stays the same.
The product companies that will survive this shift are the ones building something that a custom internal tool genuinely cannot replicate. Deep vertical products with years of domain-specific logic. Network effects that require many customers to work. Workflows so complex that a three-month custom build would take three years to get right.
Horizontal tools that charge enterprise prices for features most customers ignore are in a harder position than they realize.
Where This Is Heading
I do not think SaaS is dead. I want to be clear about that. There are entire categories of software where the product is so complex, so specialized, or so dependent on network scale that building your own is not a serious option.
But the middle layer, the horizontal tools that charge $30,000 to $50,000 a year to solve problems that are now solvable with a focused build and the right AI tooling, is going to shrink. Some of those companies will find a way to justify their price. Others will not.
My three clients made the same decision independently, without knowing about each other. That is not a coincidence. That is a pattern.
The build-vs-buy calculation has shifted. The companies on both sides of it who understand that earliest will be the ones best positioned for what comes next.
Are you at a company going through this decision right now? Or are you on the SaaS side watching customers ask harder questions at renewal time? I'd like to hear how it looks from where you're sitting.
Subscribe to the newsletter
New posts on software, AI agents, and what I learn building them. Straight to your inbox, no spam.
Discussion
Related Posts
Prompts are code. Start testing them like code.
Your prompt is the most important function in your app. Why is it the only one with no tests?
AI is a compiler, not a runtime
Everyone wants to put a model in the loop. After a while building real systems, I think most people are putting it in the wrong place.