Blog

There is a lot of noise right now about the SaaSpocalypse. Depending on who you listen to, AI is either about to destroy the software industry as we know it, or this is just another market panic dressed up as a technology story.

I’ve spent close to 30 years building software, and much of that time has been spent building and managing products used by millions of people. So I’m not particularly interested in looking at this as a stock market story, or making dramatic predictions about every large SaaS company suddenly disappearing. I’m more interested in looking at it from the builder’s side.

The squeeze starts below the enterprise tier

To me, the interesting part of the SaaSpocalypse isn’t whether the biggest enterprise platforms survive. Big companies don’t rip out core systems just because a new tool exists. There are processes, integrations, procurement, compliance and, most importantly, a lot of people wrapped around how things already work. Replacing the software is one thing. Changing the way hundreds or thousands of people work is something completely different.

What’s more interesting is what happens below that layer. What happens to the small tools, the narrow products, the things we bought not because they were impossible to build ourselves, but because building them was annoying, time-consuming or simply not worth it? That’s where I think the SaaSpocalypse starts.

Software with an expiry date

In workplaces and groups of friends, we constantly create small, temporary needs for software. Maybe there’s an office darts tournament. Maybe it’s some internal competition. And every major sporting event, such as the World Cup 2026, inevitably creates prediction pools between friends and colleagues.

A few years ago, you’d find a SaaS product that was close enough to what you wanted. It probably wouldn’t do exactly what you wanted, but it would do 90% of it. You’d pay $15 a month because that was insignificant compared with the time it would take to build something yourself. Then you’d adapt to the product. Maybe your group wants to predict which player will score the most goals for Sweden. If the product doesn’t support that particular bet, you don’t have that bet. That’s just how it works. The product defines what you can do.

With AI, that changes. Now I can describe exactly what I want. I can define the scoring system, the rules, the bets and the leaderboard. If someone comes up with another ridiculous prediction halfway through the tournament, I can add that too. Suddenly I’m the product manager.

The application exists for exactly as long as I need it. We run it during the World Cup, declare a winner after the final, and then I can simply shut the whole thing down. There’s another small detail here that I think is worth mentioning: subscriptions. There is probably a surprisingly profitable long tail of people paying $10 or $15 a month for SaaS products they originally intended to use for a few weeks and simply forgot to cancel. Disposable software doesn’t have that problem. When the reason for the software disappears, the software can disappear with it.

Software for a single room

I see the same thing when I do public speaking or run workshops. Sometimes I want a live poll, a Q&A board or some other way of interacting with the room. Previously, that meant spending time researching which products were available, comparing their pricing models, figuring out which features were included in which tier, and eventually signing up for the one that came closest to what I wanted. Again: closest. It rarely fits exactly.

Today, I can build something specifically for that presentation or workshop. I can decide exactly how people interact with it, what gets displayed on screen, how the results work and what happens with the data afterwards. It can be completely customized for that particular room and that particular session. And if I need to keep the responses afterwards, I export them into a data-readable format and move on. The software itself doesn’t necessarily need to survive the meeting.

Do I still need Mailchimp for this?

There’s another category where the calculation is starting to change for me. Let’s say I have a product and I’ve just released a new feature. I want to email the users and tell them about it. Historically, I’d probably reach for something like Mailchimp. That means getting the users into another system, giving their email addresses to another third party, setting everything up there and then using their tooling to send the update.

There were good reasons for doing that. Building even a basic email system yourself meant spending time on infrastructure instead of the actual product. But that calculation is different now. For a relatively simple product update, I can use Amazon SES for delivery. I can handle bounces, keep a small data store for unsubscribes and send history, and put a simple admin interface on top. Then I send the update. Done.

I’m not arguing that this replaces every use case for Mailchimp. It obviously doesn’t. But for the smaller use cases, something important has changed. The question used to be: “Which SaaS product should I buy so I don’t have to spend several days building this?” Increasingly, the question is: “Would it actually be faster to just build this?” And sometimes the answer is now yes.

Why developers run this calculation differently

I know my perspective isn’t that of the average software buyer. I’ve been building software for years, and over time I’ve naturally moved through a lot of the pieces around it: development, DevOps, infrastructure, product management and understanding customer needs. I genuinely enjoy all of those things. Each piece is interesting on its own, but together they give you a pretty good understanding of how the whole system works.

So when I look at a small SaaS product, I don’t just see the interface. I see the pieces behind it. If it’s an email tool, I see something like SES handling delivery. I see bounce handling, a small data store for unsubscribes and send history, a simple admin interface and some logging so I know what happened. None of that is magic. It’s work. And historically, work was exactly why I paid for SaaS products.

I knew I could build these things myself. The people around me knew they could build them themselves. But why spend several days, or perhaps several weeks, doing that when somebody else had already solved the problem for $15 a month? We weren’t necessarily paying because the technology was difficult. We were paying to save time.

That’s the part AI changes. Something that previously wasn’t worth spending several days building can now sometimes be built in a couple of hours. And once I’ve built it, I own it, I can change it and I can reuse it.

I’m probably a little unusual in how broad my technical background is, but I’m far from unique. There are a lot of developers, technical founders, product people and small teams who understand enough of the stack to look at a SaaS product and think: “I could build the version of this that I actually need.” The reason we didn’t was time. And that time-saving advantage is rapidly disappearing.

So, is there really a SaaSpocalypse?

Probably not in the way it’s being portrayed in the headlines. Salesforce isn’t going to disappear tomorrow because somebody figured out how to vibe-code a CRM over the weekend. Enterprise software has decades of processes, integrations, data and people wrapped around it. Replacing that is a very different problem.

But there is something real happening further down. For a whole class of smaller SaaS products, particularly products solving narrow problems or problems with a short lifetime, the economics have changed. The first products to feel that aren’t necessarily the biggest or most complicated ones. They’re the products we bought because $15 was cheaper than spending two days building the thing ourselves.

AI is attacking that equation directly. Maybe the SaaSpocalypse isn’t really an apocalypse. Maybe it’s a squeeze. And I suspect we’re going to see money gradually move away from small convenience SaaS products where the primary value proposition was simply saving us the time required to build them ourselves. Because for developers and technical teams, that time is getting very, very cheap.

So, what do you think? Is the SaaSpocalypse real, or are we simply seeing the economics of small software change? I’d love to hear your take. Leave a comment below, or find me on X or Bluesky.