The SaaSpocalypse is here, and depending on your perspective, I am either part of the problem or part of the solution.
Over the past year, I have become much more of a builder and much less of a buyer of software. This does not mean that I’m now an engineer. This simply means that the Build vs Buy equation has been weighted heavily in favor of “Build” by modern AI coding.
Some people think of the SaaSpocalypse as coding agents and AI models directly replacing the functionality of existing SaaS tools, or AI native tools supplanting their legacy competitors. I think of it a little bit differently. It’s not so much that new platforms are replacing old platforms, it’s that internal platforms are replacing external platforms.
The AirOps Moment
About a year ago, I started using AirOps for an SEO project. As I built workflows and automation, I realized that there was not much secret sauce there. In fact, when I asked one of their reps if I could tune the system prompts and some of the other prompts for their platform, I was told that I could not do that because that is their IP.
Wrong answer.
So instead, I spun up an agent and had it build me an SEO/AEO platform for internal use only, complete with image generation, Webflow publishing, internal cross-linking, and SEO/AEO best practices baked in. Because it was an internal tool, I did not need to build elaborate security, tenancy, multi-user support, signup or onboarding flows, payments, or anything else. I simply built the core functionality and protected it with our VPN.
Was it as good as AirOps? No. But the results were 90% as good as AirOps. It was completely configurable, and it was 200x cheaper to run this system than to pay for AirOps.
Now I don’t mean to pick on AirOps. There is a lot in their platform that is very valuable. However, for my use case, having complete control over the application was more important than having a polished UI and team features.
The drawback here was that now I was supporting an application I had built. This is not a problem when you are a growth team of one, but becomes more complex as you have to build additional features to support a larger team with collaboration features, audit logs, etc.
If I had been doing this two years ago instead of one year ago, it would have been a clear “Buy” situation, and the decision would have been between vendors, not between a vendor and Claude’s output. Build would not have even been on the table. But the equation gets flipped as building software becomes democratized.
SaaS Slop
This has had an impact externally as well. Because building software is so easy, SaaS platforms have proliferated to the point that I would characterize most SaaS as slop.
If you’ve spent any time on Product Hunt lately, or read a thread in the SaaS subreddit (spoiler: it’s ALL shills and AEO bots), you’ve seen it. Thousands of apps, all doing roughly the same thing, all with the same three-gradient background and the same rounded corners, all built by someone who had an idea on Friday and shipped it by Sunday. Building software has gotten so easy that everyone is doing it, and the natural result of everyone building is that almost nobody is buying.
So when it comes to bootstrapped SaaS apps, the building is no longer the hard part. Finding buyers and cutting through the clutter has become the hard part. Couple the challenges of cluttered go-to-market channels with a massive proliferation of competition, and go-to-market rather than product becomes the bottleneck.
This reduces the value of the people who can build products and increases the value of people who can take them to market effectively. Given the advent of GTM agents, there is a lot that can be automated in go-to-market motions, but when everyone is doing it, no one stands out. For marketers, this places creativity at a premium, and for engineers, this places specialties like GTM engineering at a premium.
Rethinking Resource Allocation
Finally, Build vs Buy has changed dramatically with regard to resource allocation. In the past, if I wanted changes to our onboarding flow, I would need to build the appropriate user stories, make my case to the engineering managers, and get my changes prioritized alongside everybody else’s changes. So the “build” choice included opportunity cost and would come at the expense of other features that could be built.
However, now that coding agents have made adding that feature myself trivial, I simply push a PR, get a review on it (sometimes with AI), and push it live myself. I no longer have to consider sprint planning and other resource constraints because the SDLC has been compressed from ideation through deployment under one person’s purview: me.
From “Can” to “Should”
The internal calculus has also been upended by the ease of building. The question is no longer “Can we build this,” it is “Should I build this.” The “Can” is solved. The “Should” is where the value now lies. This elevates user experience judgment to one of the most important skills in a company.
Now this is not without its pitfalls. When you build instead of buy, you now have sloppily coded surface areas that need to be maintained by someone. Granted, AI agents do a quick and efficient job of maintaining, but somebody has to be there to understand what needs to be fixed. In addition, when everyone is pushing product updates, including non-engineers and non-PMs, you risk turning the platform into a complete hodgepodge of different priorities. This makes a product leader’s job include a new governance role in addition to planning and execution.
Part of the Problem
As I said, I am part of the SaaSpocalypse problem from two perspectives. First, I am now building quite a few tools I would have bought in the past. Second, I am pumping out pet projects and solo SaaS platforms (for fun and for hackathons) and cluttering up the landscape.
What’s Still Worth Buying
Not everything gets swallowed by this. The platforms unlikely to get replaced by someone’s weekend build are the actually complex ones, and especially the ones where security or team surfaces are mandatory… multi-tenancy, RBAC permissioning, audit trails, compliance, etc. Those are the things that as a team of one I did not need in my internal AirOps replacement, so building made sense. For high-compliance and larger enterprise environments many of the incumbents are probably safe for a while.
But AI coding is accelerating in its ability to replicate complex functionality, and therefore so will the SaaSpocalypse.