Its not a smart calculation to poison yourself and live shorter just because it is convenient and less work in the short term.
If anything the bread paradox should describe that it is very easy to fool 90% of the population. Eat shit and then inject ozempic. Double win... for the industry
Conventional wisdom would suggest the opposite: the big companies with more resources will obviously just decide to create their own internal version, whereas the small companies don’t have the time or resources to do that.
What actually seems to happen is that IMO if a team is nimble enough to copy a SaaS product internally, and doesn’t want to pay the $100-$1000 a month for your services, they’ll likely build it in house with AI.
However if the company is large enough, it’s coalesced into different departments with specific resources and plans, and ergo no one wants to give themselves a ton of new work when they can just outsource it to a SaaS and get corporate to pay for it.
A lot of the big SaaS stuff isn’t code or product. It’s support and hand holding.
2. Even if SaaS has only one customer it might still be cheaper to outsource a project. Big companies tend to have lots of managerial overhead - a meeting where we discuss the prospects of designing a schedule of meetings to manage the plan of meetings. This cost might be higher than profit margin of a company consisting of five dudes and a tank truck of energy drinks.
I think AI familiarity still varies a lot across companies and individuals. Small companies/startups often move much faster than large corporations, so that may also explain what you're seeing. Long before LLMs I worked at places where even monitoring solutions were implemented in-house because the vendors' pricing was extremely greedy.
My point is that I'm sure this will also change for some large corporations in the short to medium term. Not saying SaaS is doomed because it's obviously not and at the end of the day you want a battle-tested solution, but it does feel like the market will shrink.
I think a lot of SaaS are actually pretty safe, if only due to organisations desiring to make compliance someone else's problem.
We don't pay $$$ for a SaaS just because it would be time consuming to replicate it - we pay it because we'd rather not have to add the in-house replacement to our SOC2/HIPAA/GDPR compliance audit every year, and legal prefers it because there is someone else to sue if things go sideways in those areas.
Compliance is an important factor in customer retention, but the cost of the other side of the equation (technical implementation) has dropped significantly and in some cases could be what tips the balance.
The Chorleywood process created mega bakeries that displaced regular bakeries because they changed the economics. AI is doing the same and fundamentally changing the economics of production. What used to take years and huge teams to build can be built by much smaller teams much faster.
SaaS isn't going to sublimate straight into consumer built tools but the boiling point for competition has gotten a lot lower.
I'm not saying business is easy now. I'm saying that a small team of smart people can do a whole lot more with the tools available to them. You still need strategy and vision (or the ability to copy someone else's playbook) but execution is a lot cheaper.
Not really. SaaS were already trivially replaceable; it's just slightly cheaper now. But the line item is still a line item.
> What used to take years and huge teams to build can be built by much smaller teams much faster.
It takes years to develop a product, but only weeks or maybe a couple months to replace. You're greatly overestimating the work that goes into building a clearly defined product.
The expensive part for producers is figuring out what to sell and how to define the market. The expensive part for customers is burning capital while chasing after customers who would rather not think about the tools they've already committed to paying for. AI just burns the fat off of an already lean process.
Connecting your business to a SaaS is very different and comes with much higher costs if you pick a bad solution.
At the high end, big companies are loathe to trust new AI-coded-looking startups. Relationships and meetings are a lot more important at that level.
This is basically also why the cloud business was thriving even when on-prem is much cheaper in monetary terms, and why the trend will probably extend to cloud AI providers even when open weight models get better. (As an example, Linux is free, but MSFT makes a ton of money off it by renting out the hardware it runs on.)
That said, there will likely also be a very large volume of internal SaaS-y apps that enterprises will vibe-code simply because nothing on the market meets their needs and/or price point.
Another possibility is enterprises "remixing" existing SaaS apps for custom functionality by adding their own vibecoded layers on top of the SaaS endpoints. Either invoking official APIs where available, or by less official means like using custom browser extensions. Now that could lead to some interesting dynamics...
On-prem is almost always much more expensive "in monetary terms" when you take into account the cost of staffing the operation needed to maintain those on-prem systems, especially if a company has e.g. compliance requirements etc.
The idea that cloud is obviously more expensive is not actually supported by the economics. If it was, we'd see people leaving the cloud in droves, for competitive reasons.
There are of course cases where it can make sense for a company to do on-prem. But they're about as common as the cases where it makes sense for a company to generate its own electricity instead of using the local grid.
That drove consumers to some curious brands: https://en.wikipedia.org/wiki/Aerated_Bread_Company
Consumers paying attention to how products impact them. No kiddin’.
This line captures the essence of the article and is going to stick with me forever:
> SaaS is the bread, not the bread machine.
And yes, SaaS companies that understand that they sell convenience and accountability will be the ones that survive this AI rush. New ones could emerge too.
The count argument would be that building with AI will potentially give you infinite customizability, which is especially attractive if you’ve ever hit a brick wall using a line-of-business SaaS product. It works great until you hit that wall.
But again, I think this counter argument oversells the value of customization. Most users-would-be-builders would happily build a monstrosity that doesn’t even serve themselves well, if you let them. Building good workflows (and therefore good SaaS products) is not nearly as easy or straightforward as it seems.
If enough people were hitting that wall in that SaaS you mention, the SaaS would've fixed it. The barrier of starting over with a custom solution, leaving behind a SaaS they've become accustomed to, is an unlikely choice. They'd rather just come up with a convenient workaround, and briefly look at competing products.
Working in Switzerland and first Paris, it's always amusing to see the circle of outsourcing and the overall regression of skills and critical thinking in enterprise.
Or the myth that startups have some of the greatest people we working for them, meanwhile, I was a click away to be able to take over the whole Saas platform of an industrial leader, with a few 100b at stake. And their security response team was inexistant.
be the change
I had a conversation with someone the other day, trying to convince them how easy it would be to solve a problem they had by creating a quick program with Claude. They were so computer averse, so used to thinking that coding was some impossible task, that they refused to even try or let me show them.
SaaS isn't dead at all. In fact, I think we may have just entered the golden age
Since Covid, that most of our projects are fully SaaS based.
On enterprise consulting nowadays it is mostly about glueing SaaS products together via serveless/container services, called via orchestration endpoints, and latest via agentic low-code/no-code tools (also SaaS based), where microservices are now MCP tools.
Concrete example, you create the data on an headless CMS like Contentful, images via Bynder, search with Algolia, deliver the frontend via something like Vercel, the few microservices can run on AWS Lambda, Vercel Functions or be modelled in Boomi/Workato.
If anything, this is exactly the kind of scenario where classical programming languages have kind of lost their role already, more so than on microservices architectures of a decade ago.
SaaS will survive. We pay a lot for convenience. You'll never go wrong appealing to laziness ;)
AI lowers the cost of creating bespoke software that competes with both. Instead of buying a one size fits all thing that half does what you need, you can now have a thing that is a bit better suited to your needs. There will be a lot more demand for those things. A lot of these things are going to require deep domain knowledge and some system thinking skills.
This is still hard enough to do well that a lot of the creation work will be outsourced to professionals. Even if that involves the use of AI prompting. Maybe after naive attempts to do it in house fail. My hunch is that there will be a lot of growth for those that can do these types of projects efficiently and that it might more than offset the job losses in the SaaS sector.
There are a lot of of companies that are still under using software. There never was any good SaaS that fit their needs and they lacked the skills to do it themselves. When you lower the cost of something (creating software) the market usually grows. A lot of things that were previously not feasible are now doable.
Sure, if you want to put an equal amount of time into what I've built, be on the hook for maintaining the infra, probably diverge from what will end up being a stable spec, go for it. It won't be as good, it won't be as fast, you will be fighting Claude at every corner just like I did to build the right thing. But consider this: people still pay for Dockerhub even though anyone can spin up any number of open source registries. SaaS is no where near doomed, people will always pay to not have distractions from their actual core business cases.
You don’t need to support all the other customers, and you also have the exact apis and their usage.
Telling Claude to “reimplement” something is vastly more achievable than trying to spec and research and develop a totally novel idea.
And it gets much worse for the “open core” projects - you can literally get the core and vibe code all the “premium” features and don’t pay the original creators a dime … while still requiring a lot of skill to do, it is vastly more tractable than it used to be, shifting the “is it worth the time and money” point quite a lot.
My prediction is we will see a lot less open source or open core companies in the future, people are now guarding their IP much more.
Ahh, it was nice while it lasted. I’m already thinking how I will be telling my grandkids about the good old time of GitHub and open source and oss social interactions, while stroking my white beard…
Say there's a company that sells you a subscription to an issue tracker. At first, it looks just like any other web-based issue tracker. But, although you won't realize it at first, it's hosted on a Linux VM with a development environment on it. Each customer's app gets built from source.
Then, when you want something changed, you send a message to support. And they just bounce it to a coding agent that edits the source code and rebuilds it.
The sort of customization that enterprises used to pay big bucks for is going to get dramatically cheaper.
(There are technical issues making this safe, but I think they'll be solved.)
I believe LLMs are going to make the bar for a SaaS you would pay for, as a company, higher.
One major difference between SaaS and bread is the number of varieties in SaaS is much more than that in bread. If you need to customize something for a specific workflow, you can now make your own software than buy something off the shelf and settle for something substandard.
One thing to add: software maintenance costs. The build has never been the bottleneck.
The notion that most companies will suddenly institute developers to build all kinds of software inhouse and maintain it is silly. Most companies are not google et al, even in 2026.
The insurance industry built almost everything custom in the 70s and 80s, simply because that was the only option. The more software became commercially available elsewhere the more this effort was pruned back.
Another thing: knowing what to build — another big bottleneck. Most people cannot articulate what they want and even fewer can articulate it at a level that would enable them to build durable software, even with AI. Case in point: the majority of AI-built stuff you see are point solutions or small productivity items, etc. “Systems thinking”, as some people call it, is hard, even for most software engineers.
Yes, you can “rebuild” tools you’ve previously purchased as SaaS but at some point you gotto use your brain to come up with something new. Systems thinking on blank-page challenges is even harder…
- browser extensions where a bookmarklet will do (media speed control)
- tolerate-able UX where alternatives available (e.g LLM chat interface without a table of contents is a pain to me, vibe coding an extension took me less than 1 session worth of credit)
- buying bulk vs buying individually
- doomscrolling vs reading a book
- standing vs tip toeing (one I discovered only very recently that I can tip toe any time to train my toes for climbing, no need dedicated training sessions)
- getting angry/depressed online vs realising most thing on internet is about provoking emotion
I spoke to the CTO of a well funded company who was spending a few millions on AWS infrastructure per year with budget overshoots etc. I pitched the product to him with all the details and he understood it but at the end of the day, his response was that he'd rather pay AWS for the convenience rather than manage this by himself.
The math has changed for sure, but there is still a large open space in the convenience vs cost equation.
Don’t we all know the cycle by now?
1. Company pours money and resources to create good product
2. Good product gets customers and those customers use word of mouth to get product viral and even more customers
3. Eventually the company has to make a profit and in that pursuit, they make the product worse by adding ads, adding paywalls, forcing login or subscription service, dark patterns
I’ve seen it happen with so many products I used that I only use open-source now. And if the feature is small, I just build it myself. In your bread example, open-source is the ultimate cookbook and chefs who understand that cookbook can out cook the best chefs out there.
Of course, it’s possible other things can drive step 3.
And frontier models are already a study in unusual levels of resources dedicated to step 1.
Open-source on the other hand, isn't profit-driven as much. The builder is making it for himself and for the love of it. Give me that bread maker 10/10 times. And yes, that bread maker might also start to chase profits and make the bread worse, but I can fork his product and be on my merry way if he does.
SaaS products do have their own problems sometimes, such as feature creep and bloat and uptime, but those are less insidious.
I have relatives who share sourdough starter yeast and make their own bread.
Naw, I can see I think the case being made - a lot of people still do things they don't need to, well after they don't need to do them, so SAAS may have a place for a while
I think for the rest of us though, SAAS may want to "pivot" to something else...
This means when you fly on a 747, you're building a millionth of a 747 and are flying that. You don't actually need to build a full 747.
Then there is the doctrine of static comparative advantage, where basically all traits are geographic or inborn and unchanging. If someone builds an SaaS, you can always claim that you have a unique comparative advantage for the particular industry you are working in so you always know better what kind of niche software requirements you have.
Meanwhile if you take a simple liquidity theory oriented approach you realize something very obvious: borrowers promise a big illiquid chunk of real physical capital that can only exist as one big monolithic unit and the bank creates a corresponding liquid asset in the form of coupons that can be used to acquire just a fraction of the monolithic unit. The airline buys a 747 using borrowed money, thereby making your dollar a fraction of a 747.
From this perspective it is completely obvious why specialization exists: You only need a fraction of the full investment. If everyone were to buy a personal 747, they might be able to fly, but each 747 has a 0.000001% utilization. Each 747 is a 99.999999% unconsumed asset that can be sold. Specialization occurs because you can bundle these fixed costs and the higher utilization leads to a lower cost per flight because you're not constantly buying 747s for a single flight. If you see that someone else already has a 747, it is economically illogical for you to buy one even if you could afford the full 747, because you could just pay the cost of a single flight instead.
Outsourcing (=specialization) occurs whenever you do not consume the full output of a fixed investment. It's that simple.
Now flip the script and assume you're an airline that is constantly running their aircraft at maximum or near maximum utilization? You would never rent the aircraft and just own them outright. You're consuming the full output of the aircraft.
If you apply this same logic to a SaaS company you end up with the same conclusion: You can vibe code it, but your utilization rate is going to be way less than 10% of what you could pull out of the vibe coded software. Hence even with vibe coding, it would be in your interest to just let someone else vibe code the software on your behalf. If vibe coding works it doesn't change the idea of SaaS, it just creates a race to the bottom in terms of margins and cost for the end user.
Saas isn't doomed, but it is going to be Commoditized. so you win on price, volume, execution, and cannot simply sell user seats to scale.