We spent fifteen years watching software eat the world. Entire industries got swallowed by software - retail, media, finance - you name it, there has been incredible disruption over the past couple of decades with a proliferation of SaaS tooling. This has led to a huge swath of SaaS companies - valued, collectively, in the trillions.

In my last post debating if the cost of software has dropped 90% with AI coding agents I mainly looked at the supply side of the market. What will happen to demand for SaaS tooling if this hypothesis plays out? I’ve been thinking a lot about these second and third order effects of the changes in software engineering.

The calculus on build vs buy is starting to change. Software ate the world. Agents are going to eat SaaS.

The signals I’m seeing

The obvious place to start is simply demand starting to evaporate - especially for "simpler" SaaS tools. I’m sure many software engineers have started to realise this - many things I’d think to find a freemium or paid service for I can get an agent to often solve in a few minutes, exactly the way I want it. The interesting thing is I didn’t even notice the shift. It just happened.

If I want an internal dashboard, I don’t even think that Retool or similar would make it easier. I just build the dashboard. If I need to re-encode videos as part of a media ingest process, I just get Claude Code to write a robust wrapper round ffmpeg - and not incur all the cost (and speed) of sending the raw files to a separate service, hitting tier limits or trying to fit another API’s mental model in my head.

This is even more pronounced for less pure software development tasks. For example, I’ve had Gemini 3 produce really high quality UI/UX mockups and wireframes in minutes - not needing to use a separate service or find some templates to start with. Equally, when I want to do a presentation, I don’t need to use a platform to make my slides look nice - I just get Claude Code to export my markdown into a nicely designed PDF.

The other, potentially more impactful, shift I’m starting to see is people really questioning renewal quotes from larger "enterprise" SaaS companies. While this is very early, I believe this is a really important emerging behaviour. I’ve seen a few examples now where SaaS vendor X sends through their usual annual double-digit % increase in price, and now teams are starting to ask "do we actually need to pay this, or could we just build what we need ourselves?". A year ago that would be a hypothetical question at best with a quick ‘no’ conclusion. Now it’s a real option people are putting real effort into thinking through.

Finally, most SaaS products contain many features that many customers don’t need or use. A lot of the complexity in SaaS product engineering is managing that - which evaporates overnight when you have only one customer (your organisation). And equally, this customer has complete control of the roadmap when it is the same person. No more hoping that the SaaS vendor prioritises your requests over other customers.

The maintenance objection

The key objection to this is "who maintains these apps?". Which is a genuine, correct objection to have. Software has bugs to fix, scale problems to solve, security issues to patch and that isn’t changing.

I think firstly it’s important to point out that a lot of SaaS is poorly maintained (and in my experience, often the more expensive it is, the poorer the quality). Often, the security risk comes from having an external third party itself needing to connect and interface with internal data. If you can just move this all behind your existing VPN or access solution, you suddenly reduce your organisation’s attack surface dramatically.

On top of this, agents themselves lower maintenance cost dramatically. Some of the most painful maintenance tasks I’ve had - updating from deprecated libraries to another one with more support - are made significantly easier with agents, especially in statically typed programming ecosystems. Additionally, the biggest hesitancy with companies building internal tools is having one person know everything about it - and if they leave, all the internal knowledge goes. Agents don’t leave. And with a well thought through AGENTS.md file, they can explain the codebase to anyone in the future.

Finally, SaaS comes with maintenance problems too. A recent flashpoint I’ve seen this month from a friend is a SaaS company deciding to deprecate their existing API endpoints and move to another set of APIs, which don’t have all the same methods available. As this is an essential system, this is a huge issue and requires an enormous amount of resource to update, test and rollout the affected integrations.

I’m not suggesting that SMEs with no real software knowledge are going to suddenly replace their entire SaaS suite. What I do think is starting to happen is that organisations with some level of tech capability and understanding are going to think even more critically at their SaaS procurement and vendor lifecycle.

The economics problem for SaaS

SaaS valuations are built on two key assumptions: fast customer growth and high NRR (often exceeding 100%).

I think we can start to see a world already where demand from new customers for certain segments of tooling and apps begins to decline. That’s a problem, and will cause an increase in the sales and marketing expenditure of these companies.

However, the more insidious one is net revenue retention (NRR) declines. NRR is a measure of how much existing customers spend with you on an ongoing basis, adjusted for churn. If your NRR is at 100%, your existing cohort of customers are spending the same. If it’s less than that then they are spending less with you and/or customers are leaving overall.

Many great SaaS companies have NRR significantly above 100%. This is the beauty of a lot of SaaS business models - companies grow and require more users added to their plan. Or they need to upgrade from a lower priced tier to a higher one to gain additional features. These increases are generally very profitable. You don’t need to spend a fortune on sales and marketing to get this uptick (you already have a relationship with them) and the profit margin of adding another 100 user licenses to a SaaS product for a customer is somewhere close to infinity.

This is where I think some SaaS companies will get badly hit. People will start migrating parts of the solution away to self-built/modified internal platforms to avoid having to pay significantly more for the next pricing tier up. Or they’ll ingest the data from your platform via your APIs and build internal dashboards and reporting which means they can remove 80% of their user licenses.

Where this doesn’t work (and what still has a moat)

The obvious one is anything that requires very high uptime and SLAs. Getting to four or five 9s is really hard, and building high availability systems gets really difficult - and it’s very easy to shoot yourself in the foot building them. As such, things like payment processing and other core infrastructure are pretty safe in my eyes. You’re not (yet) going to replace Stripe and all their engineering work on core payments easily with an agent.

Equally, very high volume systems and data lakes are difficult to replace. It’s not trivial to spin up clusters for huge datasets or transaction volumes. This again requires specialised knowledge that is likely to be in short supply at your organisation, if it exists at all.

The other one is software with significant network effects - where you collaborate with people, especially external to your organisation. Slack is a great example - it’s not something you are going to replace with an in-house tool. Equally, products with rich integration ecosystems and plugin marketplaces have a real advantage here.

And companies that have proprietary datasets are still very valuable. Financial data, sales intelligence and the like stay valuable. If anything, I think these companies have a real edge as agents can leverage this data in new ways - they get more locked in.

And finally, regulation and compliance is still very important. Many industries require regulatory compliance - this isn’t going to change overnight.

This does require your organisation having the skills (internally or externally) to manage these newly created apps. I think products and people involved in SRE and DevOps are going to have a real upswing in demand. I suspect we’ll see entirely new functions and teams in companies solely dedicated to managing these new applications. This does of course have a cost, but this cost can be often managed by existing SRE or DevOps functions, or if it requires new headcount and infrastructure, amortised over a much higher number of apps.

Who’s most at risk?

To me the companies that are at serious risk are back-office tools that are really just CRUD logic - or simple dashboards and analytics on top of their customers’ own data.

These tools often generate a lot of friction - because they don’t work exactly the way the customer wants them to - and they are tools that are the most easily replaced with agents. It’s very easy to document the existing system and tell the agent to build something, but with the pain points removed.

SaaS certainly isn’t dead. Like any major shifts in technology, there are winners and losers. I do think the bar is going to be much higher for many SaaS products that don’t have a clear moat or proprietary knowledge.

What’s going to be difficult to predict is how quickly agents can move up the value chain. I’m assuming that agents can’t manage complex database clusters - but I’m not sure that’s going to be the case for much longer.

And I’m not seeing a path for every company to suddenly replace all their SaaS spend. If anything, I think we’ll see (another) splintering in the market. Companies with strong internal technical ability vs those that don’t. This becomes yet another competitive advantage for those that do - and those that don’t will likely see dramatically increased costs as SaaS providers try and recoup some of the lost sales from the first group to the second who are less able to switch away.

But my key takeaway would be that if your product is just a SQL wrapper on a billing system, you now have thousands of competitors: engineers at your customers with a spare Friday afternoon with an agent.