For the better part of two decades, the answer to almost every software problem was the same: subscribe. There is a SaaS for that. Pay monthly, get access, let someone else handle the infrastructure, the updates, the security patches. The model worked beautifully — for vendors.
Now companies are looking at their software stack and doing the math differently.
The SaaS fatigue is real
The average mid-sized company now runs 80 to 200 SaaS applications. The average enterprise runs far more. The costs compound: per-seat pricing that scales with headcount, annual contracts that lock you into features you no longer use, integrations that require their own tools to manage, and data siloed across dozens of systems that were never designed to talk to each other.
The CFO who once celebrated moving off expensive on-premise infrastructure is now staring at a SaaS bill that rivals what they used to spend on servers — with less control and worse data portability.
What AI changes about the build-or-buy calculation
The traditional argument for buying was simple: building is expensive. You need engineers, maintenance, iteration. A SaaS vendor amortizes that cost across thousands of customers and delivers a solution that is usually good enough.
AI coding tools are disrupting this calculation. A small team with AI-assisted development can now build and maintain internal tools that would have required a dedicated engineering team two years ago. The cost of building has dropped significantly. The cost of buying has not.
For use cases that are genuinely generic — project management, HR, accounting — buying still makes sense. The vendor’s investment in the problem exceeds what you can justify internally. But for use cases that are specific to how your company operates, the build-or-buy equation is shifting.
Where the smart money is going
The most interesting companies right now are doing something in between: they are buying platforms and building on top. A database, a compute layer, a set of AI APIs — and then building the specific workflows and interfaces their teams actually need.
This is not a rejection of SaaS. It is a more sophisticated version of the same insight that drove SaaS adoption in the first place: do not build what someone else has already solved. But know what is worth building — because that is often where your competitive advantage lives.
The era is not over
SaaS is not dying. But the days of defaulting to a SaaS subscription for every problem, without seriously evaluating the build option, are ending. The next era belongs to companies that are selective about what they buy, deliberate about what they build, and honest about the difference between the two.