The future of SaaS

Software engineers have always had this obsession with building things. And if you love the craft of making things, you will probably end up building things that do not need to be built.

Once you have worked at enough companies, you start to notice a pattern. Most of them end up building something that already exists and is probably better than what they have. Looking back at my career, I think the only company I worked for that genuinely needed to build its own tools and systems from scratch was Google. Everyone else was either suffering from the “not invented here” syndrome or just had people who wanted to build things for their own reasons.

For a long time, I was on the opposite side of that argument, and to some extent, I still am. But I should clarify something. When I say “if something already exists, just use it,” I am mostly talking about FOSS.

That was true for a long time, especially when you could adopt a solid FOSS tool and get the job done. A few times, my teams and I adopted something that was not exactly what we wanted, but was close enough. I sent a few PRs over the years to a couple of OSS projects just to get a little feature here and there, and that was it. Kelsey Hightower even has that tongue-in-cheek GitHub repository called “no-code”. If you do not have to write code, then do not. It is cheaper, easier, and if you contribute back, everybody is better off.

But that is not the same as saying companies should always buy paid software instead of building. That is a different tradeoff entirely. For more than a few years now, many of the cool, useful tools are no longer FOSS. They are SaaS products with subscriptions. And once you move from adopting FOSS to paying recurring SaaS fees, the equation changes a lot. Building something in-house may actually end up costing less in the long run.

Then AI coding agents entered the picture and forced everyone to rethink their assumptions again. It may actually become reasonable to reinvent the wheel. Heck, I would not be surprised if someone ended up with a better wheel after running auto-research for a few cycles.

You could even see that idea reflected in the stock market a few weeks ago, when many SaaS companies took a big hit. A lot of analysts seemed to realize that someone with a Claude Code subscription could suddenly replace certain SaaS services with their own custom tools.

I think there is some truth to that, but the reality is much more nuanced.

If you are SaaS company number 45 in the to-do list market, I am sorry. Even basic AI tutorials are already telling people to build their own to-do list app. You are in trouble.

Many SaaS services provide more than just a list of features. They usually sell some combination of domain knowledge, convenience, and operational responsibility.

Domain knowledge involves highly specialized business logic specific to a given industry. Think insurance, human resources, or taxes. The general knowledge about those fields is, of course, available somewhere. But it is usually scattered, paywalled, restricted, confusing, and always changing, especially in highly regulated areas with country- and region-specific differences. These SaaS companies are not just giving you infrastructure and a few CRUD APIs. They are packaging a body of knowledge that adds real value.

Convenience is another big part of it, but convenience alone does not fully describe what many of these companies sell. In many cases, what you are really buying is the burden they remove from your shoulders. You are paying someone else to deal with uptime, patching, backups, security, compliance, integrations, deliverability, support, and all the ugly operational details that start showing up the moment your quick internal tool becomes something people depend on.

I recently found myself wanting to start a newsletter. I have Claude Code, I have Codex, I have Cursor. So I naturally started building my own newsletter management system. But then I ran into all the annoyances that come with email systems, DNS configuration, security, and the rest of it. After a few hours of messing around, even while using a third-party tool to send the email, I decided to stop and use something that already existed.

I think the same applies to other kinds of SaaS, like Shopify or 1Password. Sure, you can build your own shopping cart or host your own password solution. But in those cases, you are not only paying for convenience. You are also paying for trust, maintenance, reliability, and the ability to offload a problem to a company whose whole business is dealing with it.

It is hard to predict the future, especially with how fast things are moving. But I do not think the outcome is simply “SaaS dies” or “SaaS wins.”

I think AI is pushing in both directions at the same time. On one side, it is making it much easier for individuals and companies to replace narrow SaaS tools with internal or self-hosted versions tailored to their exact needs. On the other, it is also making it much easier for engineers to create entirely new products, which may lead to an explosion of both FOSS and SaaS offerings.

So my current view is not that SaaS is going away. It is that the bar is going up. Weak SaaS, bloated SaaS, and easily replicated SaaS will have a hard time. But software that offers real domain knowledge, trust, convenience, or takes meaningful operational burden off your plate may do just fine, and perhaps even benefit from this new environment.

In other words, AI may make a lot of SaaS disappear and also create a lot more of it.

I am curious to see what people build next, and how we will end up consuming it.