You Didn’t Replace Your SaaS Vendor. You Became One.
AI makes bespoke software dramatically cheaper to build, but replacing SaaS means taking ownership of the software, its maintenance, and its consequences.

I recently replaced my scheduling stack with a custom availability aggregator. I also built my own e-signature flow. Neither effort was meant to save money. In fact, my cloud bill went up by roughly what the scheduling subscription would have cost. What I gained instead was control over the workflow, the data, the customer experience, and how quickly I can change all three.
I’m writing this because the market has spent much of this year repricing SaaS companies around the expectation that AI will make it much easier for companies to build what they used to buy.
That expectation is grounded in real behavior, but we’re being imprecise about what exactly is being replaced and why.
Why “I built it in a weekend” is misleading
I don’t have 90% of the features a mature e-signature platform offers. I don’t even know what most of them are.
A commercial product’s feature set has to cover what many different customers might need. Any individual customer needs only a subset. By encoding your own workflow assumptions, you aren’t building the same artifact faster. You’re building a categorically smaller artifact and calling it by the same name.
Why doing it yourself makes sense anyway
One word: ownership.
The code that handles my data and mediates my customer experience now behaves exactly the way I want it to. If I want to change the scheduling logic tomorrow, I write a prompt instead of waiting for somebody else’s roadmap.
That control can be difficult to price. A subscription buys functionality, but it also means accepting someone else’s abstractions, priorities, constraints, and pace of change. For some organizations, owning a strategically important part of the workflow may be worth the development effort even when it doesn’t save money.
What changed is that control got cheap.
A bespoke system doesn’t need to be a general-purpose product. You don’t need subscription billing, generic onboarding, or support for customers and workflows you don’t have. Documentation can be narrower, permissions can be simpler, and integrations can be limited to those you actually use.
The system is much smaller, and AI has made building it dramatically cheaper.
There are signs of the shift already. Retool surveyed 817 builders and found that 35% of teams had already replaced at least one SaaS tool and 78% planned to build more. Retool has an obvious interest in this trend, but the direction is believable.
But now you are the vendor
Ownership comes with the other half of the bargain: the moment your bespoke system ships, you become its vendor. Every new requirement lands on your desk.
You also own the routine maintenance: if an API is deprecated, you own the migration; if a dependency develops a vulnerability, you own the patch; if a browser changes behavior, an identity provider changes policy, or a framework breaks compatibility, the problem belongs to you.
You didn’t eliminate the vendor. You moved the vendor inside the office.
My upkeep cost for both systems is low so far. But year one tells you very little about year five. For long-lived software, maintenance and evolution have historically consumed the majority of lifecycle cost, with estimates varying widely.
AI has dramatically reduced the cost of building many software systems. It may reduce maintenance costs substantially too. Agents are already becoming useful for upgrades, migrations, testing, and debugging. But the evidence is much stronger today for AI reducing the cost of creation than for reducing the burden of ownership to the same extent.
The real comparison isn’t a recurring subscription versus a weekend build. It’s a recurring subscription versus taking ownership of a software system.
The cost nobody prices in
The other risk isn’t technical. It’s organizational.
The interesting detail in Retool’s data is that 60% of respondents had built software outside IT oversight in the past year. Software can now enter an organization without triggering the institutional machinery that used to accompany a major software implementation.
That machinery was bureaucratic for a reason. Procurement creates records, security review creates accountability, and somebody becomes responsible for access, backups, compliance, and continuity.
When software becomes cheap enough for one employee to build between other responsibilities, it can become operationally important before the organization realizes it owns a new piece of infrastructure.
The danger is that the company quietly becomes dependent on software that was never treated as infrastructure. Five years later, the original authors are gone and nobody understands how it works or who owns keeping it running.
So is SaaS actually in trouble?
Yes. Just not all SaaS equally. AI is changing the build-versus-buy boundary.
There are software categories where the value of buying becomes clearer precisely because building is getting easier: payroll, payments, identity, tax, compliance, and security. What makes these products difficult to replace may be deep integrations, proprietary data, regulatory responsibility, hard-won operational knowledge, or thousands of ugly edge cases.
If the moat isn’t in the code, rebuilding the code doesn’t get you what you were really paying for. The question is whether you want to own the consequences. AI is eroding the advantage of paying someone else to build software much faster than it is eroding the advantage of paying someone else to own the consequences. That is a distinction I think much of this year’s SaaS repricing has overlooked.
The new build-versus-buy line
While everyone is talking about the elusive moats, I think the better question is:
Which parts of your software stack are strategically valuable enough that you want to own them, and which responsibilities are you happy to rent?
I don’t think AI means the end of SaaS. It does mean SaaS has to justify itself differently. The vulnerable software vendor sells functionality that its customers can increasingly reproduce.
The durable software vendor sells something harder to bring in-house: relief from responsibility.
The winning products will be the ones whose customers can say:
We could build this ourselves. But we don’t want to own it.