The bread paradox: why convenience always wins, and why SaaS isn't doomed | Hacker News Reader

The bread paradox: why convenience always wins, and why SaaS isn't doomed

joanwestenberg.com

133 pointssrijan4119 comments

I work for a SaaS and we recently had an interesting situation where we lost some smaller customers but are in the process of getting dramatically larger ones at the same time. As in, we lost some customers that were roughly 20-people companies, but gained some customers that are 100+-people companies. The ones we lost seem to have just built our solution in-house, presumably with AI helping.

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.

Seen similar. They will be back when they realise the vibe coded SaaS run by two people in a trailer park isn’t what it looked like.

A lot of the big SaaS stuff isn’t code or product. It’s support and hand holding.

Your last phrase is bang in on the money.

Also the assurance it won't evaporate one day

Yeah we have actually have to prove to some enterprises that we have a certain level of staffing.

And AI cannot do support + hand-holding?

I'm one of the most pro-AI support/solutions/FDE engineers you'll find, and I really don't see AI taking away support and hand holding.

Even though I use AI to answer questions large customers would still rather wait for a weekly meeting to ask a question or have someone fly onsite then write the same question in an email or to a chatbot and get a near instant answer

Have you tried actually pretending to be human when replying to support? In many scenarios it leads to the same satisfaction

We did that and our customer satisfaction tanked and the query logs were full of "fuck off and tell me how to speak to someone". This was as I expected it would be.

You really think people will give you any respect or interest if you stick something between them and you? How

That is, until a given SaaS becomes too greedy and someone identifies the core features people actually use, then spends a few weeks replicating them internally.

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.

> That is, until a given SaaS becomes too greedy and someone identifies the core features people actually use, then spends a few weeks replicating them internally.

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.

Yeah, this is basically why I as a landlord have an agent who takes 10%+VAT just to know what the rules are and who to call when things go wrong, and then bills me on top for listing the property when empty, any works that need doing etc.

I'm aware of the responsibility shifting here but even then my point still stands. I've seen some SaaS companies tighten their grip thinking "they'll never bother because of the regulatory burden" only to watch large customers walk away and build in-house solutions instead. Super common? No, but this was pre-LLM and slightly later.

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.

Greed and inefficiency is what define SaaS. Compare what Microsoft give you for 50 bucks per month vs Atlassian or any ticketing services. It's absurd. They can charge up to $80/month for what shouldn't cost more than $5.

Looking at some of the pricing and then multiplying it by 12 and ask question would you pay this for shrink wrapped software is bit eye opening. At least from not filthy rich Europen perspective.

Not to say that some products like MS aren't seemingly very good value. But on other side like chat and source control I do raise eye brow...

1. If multiple companies use given SaaS, then "per company" cost is likely to be lower than in-house solution. Think of tools that have wide range of use cases, like Windows or Photoshop.

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.

Smaller companies might either want to utilize their employees better, avoid ever increasing Saas subscriptions, while larger ones will just defer responsibilities on suppliers, it's just easier to blame your suppliers for any faults.

Smaller companies probably use a small subset of the features in the SaaS. This means one of two devs with an AI can implement the used subset fairly easily.

Bigger companies probably use more features and have more advanced requirements and the SaaS is integrated in different ways within different departments of the company. This means more developers are required, more interaction with different departments and thus less benefits of AI versus the traditional way of developing without AI (as the actual work is more in coordination, specification etc, than the actual coding bit).

Larger companies also have some other traits that lend themselves to prefer SaaS:

They usually need much more than an AI MVP product. They’ll tend to have a lot more different scenarios covered by one product category. For example, a small company looking for a PAM tool might only need to access Linux servers over SSH and PostgreSQL databases, while a large company might also have a mix of Windows servers, Oracle databases, and a complicated org structure with subsidiaries and acquisitions.

Large companies also need their SaaS tools to outsource compliance, not use pure functionality. They need to be able to tell customers “vendor XYZ handles ABC and they are certified under 123 standard.”

Finally, I also think larger companies, perhaps counterintuitively, have more of a cognitive limit or something you might call an aversion to a bus factor.

A small team with a more focused set of tools and products can more easily deal with something bespoke. Fewer people need to be able to work with something like that. Larger companies with bigger teams need to be able to tap into a labor market that can work with a more standardized toolset. Maybe they even deal with higher turnover.

The risk for SaaS isn't that customers will build their own but that the barrier to entry for competitors is lower.

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 don’t agree. I think businesses including SaaS are not primarily their tech, but are mostly composed of other functions: sales, marketing, customer success, product management, strategy etc. The value is actually more in these other components than in the code.

For some businesses yes, but for many no, the software and the infrastructure are all that matters and hopefully they don’t touch what works and don’t add features no one asked for.

Sure, but code isn't the only barrier that's been lowered. A competent entrepreneurial team can also scale their sales, marketing and customer success workflows with AI.

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.

Agree the functions aren't primarily their tech, but all of their activities ends up serving a business outcome, usually manifested in code (with much distilled or cut along the way). Marketing, PM, and strategy aren't directly shipping slides or docs to production - but they should get distilled into code that ships to fulfill the activity's productivity (decisions, features, etc.).

> AI is doing the same and fundamentally changing the economics of production.

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.

Yes, I don’t know why a lot of this articles oversee this fact. Economics of SaaS will change not because customer will build their bakeries, there will be tons of bakeries selling cheaper bread.

for enterprise level dependability and support should normally be the winner.

There’s a very low cost to buying bad bread: you throw it away and don’t go there again.

Connecting your business to a SaaS is very different and comes with much higher costs if you pick a bad solution.

This is only relevant at the lower end, when you don’t really care about the company you’re paying, as long as it fixes your issue.

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 could start a race to the bottom where only large SaaS variety stores survive. They all will have a "Jira" in their portfolio.

Competitors was always possible even before AI, you could hire cheap and good developers you build almost anything even without AI, marketing and sales are more valuable when dealing with competition not devs/engineering

Building alone isn’t the solution. Finding distribution is.

yes, this is the point the article completely glosses over. the threat isn't that a non-technical founder is going to build their own custom CRM, but that a couple of college kids in a dorm can build something that can compete against your SaaS in a weekend. While the cost of software production drops to zero with the advancement AI and with newer model being better than ever, the market gets flooded with infinite cheap alternative. If I see another calorie tracking AI SaaS, I'm going to lose it.

Unlike most articles that butcher an analogy so badly that you wish they could have just described the concept plainly, this one uses the analogy really well. It carries it from start to finish without overstretching it.

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.

spot on

I think this is true, but there's also another thing here: The software market is incredibly complex, and much of the "SaaS is dead because I can vibe-code custom software" voices don't understand why certain products are bought.

Let's take project/task management stuff. You can vibe-code a kanban board, task tracker with different statuses, and project folders quite easily.

For my personal use, I can probably build a "better" Jira. I could have an agreeable interface, a data model molded to the types of projects I work on and how I work on them, useful constraints that assuage my weaknesses (e.g. you can't have more than 3 active projects), and a persistent list of things I've shipped to combat imposter syndrome.

That solution would be far too opinionated to scale across even a small team, let alone an enterprise.

Companies buy Jira because it integrates with just about everything, because it's the de-facto standard so you don't need to teach people how to use it, and because you have all the SSO, workflows, approval policies, RBAC, etc. anyone could want.

SaaS vendors don't compete to offer the core features, but the genuinely hard stuff.

Integrations are good. But most people don't need ALL integrations, there's just a couple that are show stoppers, and even then it probably doesn't integrate how you want it to. I think the future is a platform with a good data model that people can vibe code plugins on top of.

Most people don’t need all the integrations (I‘d even say most need very few).

But:

1. As companies grow, customers continue to want more integrations.

If you imagine a massive matrix of companies and all the tools they use, you need to expand the number of rows where your product is a viable solution.

This matters for implementation now (any tool must work with your stack) and for your long-term prospect of using a product since companies expect to migrate, add, or retire tooling.

2. I think the problem with a vibe-codeable plugin platform is “what is a good data model” because that depends principally on what a tool is for.

... and once you take more than the tiniest step beyond the defaults, the difficulty of configuring all that complex optionality exceeds the difficulty of coding your own, and coding the integrations you actually need. And you still get screwed when the vendor decides to make a change, or refuses to support some niche thing you need in favor of some niche thing a few more users need. Not to mention the security nightmare.

SaaS was mostly a bad deal before "AI".

This went straight from medieval guilds to the 1920s, but actual bread mass production started in the Victorian era, and people did have a big negative reaction to that. They adulterated bread in ways that poisoned consumers during that period, which was a tad unpopular.

That drove consumers to some curious brands: https://en.wikipedia.org/wiki/Aerated_Bread_Company

> They adulterated bread in ways that poisoned consumers during that period, which was a tad unpopular.

Consumers paying attention to how products impact them. No kiddin’.

Specifically, copper sulfate was added to flour to slow the rate of fermentation. Highly toxic.

I completely agree that people are vastly undervaluing convenience, reliability and SaaS being essentially a great way to make something “someone else’s problem”.

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.

also the counter argument is that median saas company is outsourcing to AI anyway, that being artificial intelligence or actual Indians

What is not outsourced to India or nowadays, Portugal for Europeans/Switzerland?

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.

just do it!

be the change

I believe customization isn't as highly valued by regular people. Just look at your friends' phones and how they haven't usually done anything to customize their experience.

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.

The underlying MBA principle is that companies strongly prefer to focus on their "core competencies." This makes sense because the distraction to a business could be much costlier than the extra money spent in outsourcing non-core functions.

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...

> This is basically also why the cloud business was thriving even when on-prem is much cheaper in monetary terms

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.

I am not convinced by that. What are you defining as "cloud" here? If you mean SaaS I interpreted GP as meaning the likes of AWS which still leaves you doing a lot of the expensive stuff.

> 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.

You are assuming that 1) the people making the decisions have perfectly aligned incentives 2) that they have got the economics right and 3) its a significant part of their cost base. In reality it is often the case that something like AWS is the CYA choice (if an AWS data centre is down its their fault, if on-prem is down its your fault), its the shareholder's money, and its cheap compared to the rest of your costs. If something is 0.5% of your fixed costs no one is going to notice that it could be 0.1%.

You will still need as many people to manage these systems, that's the biggest lie in Saas solution.

I'd say it's more of a rent vs buy situation, in that there is a particular company-specific scale at which the TCO's cross over. For smaller companies, public clouds absolutely make more sense, but at larger scales on-prem is much cheaper (see e.g. BaseCamp's recent shift with numbers.)

The reason I say that a primary driver is a focus on core competencies because there are a surprisingly high number of companies with 10M+ public cloud spends... and even they sometimes complain about being treated as small potatoes. (For reference BaseCamp's spend was 3.2M/year when they decided to switch back.) Plus there are reports showing that much of these cloud deployments are at abysmally low levels of utilization (like 30% at best!)

So not only are there many companies at the scale where on-prem would make sense, they are likely even wasting a significant % of their cloud spend, yet they continue and even expand their usage.

Rather than attributing this to widespread corporate incompetency, a more rational explanation is that they have a sensible calculus that is based on more than solely financial numbers, i.e. the organizational distration is more expensive than the $$$ cloud premium.

This is one of the best articles I've seen come across HN lately. You presented a well structured argument, and one I strongly believe in.

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

> we may have just entered the golden age

How so?

Because it invites more competition. Previously, if there was one vendor but they sucked, you just had to put up with them and use them anyway. Now, if they suck that much, someone's going to come along and eat their lunch.

I think it could go either way because what I consider calcification of choices because of AI.

We've all seen people outsourcing their thinking to AI. "Hey Claude, I need bug tracking which product should I use?" Claude then recommends Jira because it's the defacto standard as of 2026. This leads to Jira getting even more popular, leading to subsequent training data keeping it as the defacto standard.

Same issue for development technologies. React/Typescript will never ever go away thanks to coding agents.

SaaS partially took the place of bespoke projects that people were doing before. They never stopped doing those of course and there were also off the shelf packages that people bought before SaaS.

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.

Convenience is often more important than the traditional price vs quality tradeoff. Water is free. The convenience of bottled water is worth a lot. Apple's "it just works" was marketing gold that recognised the importance of convenience relative to price and performance (something many, many 'computer enthusiasts' never understood).

SaaS will survive. We pay a lot for convenience. You'll never go wrong appealing to laziness ;)

Not to nitpick but I don't think Apple ever literally marketed "it just works". It just does.

> "Step one: Plug in. Step two: Get connected. Step three... there's no step three."

-Jeff Goldblum, iconic 1998 Apple iMac G3 commercial

The point isn't that people will vibecode their own SaaS. It could mean the end of extremely high-margin software businesses, as building cheaper, better alternatives becomes easier. You'll see more people with deep domain expertise trying their hand at startups. For example, Atlassian employees with Jira expertise leaving to build niche alternatives.

> AI-generated code has about 1.7 times as many major issues as code written by humans

That's a very specific number I'd love to know the source of (and investigate further.)

SaaS is indeed not going anywhere.

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.

The common question I get asked about building my SaaS: "What's to stop customers from making their own?"

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.

It’s not equal amount of time though.

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…

That depends on the domain.

My guess is that SaaS will be around, but it's going to look really different.

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.)

Maybe I'm a luddite, but this seems far fetched, to me. I just don't see a path for LLMs to make all kinds of changes to a codebase from non-technical people, correctly. Yes, LLMs can do amazing things, but they still don't have a mental model of what a thing is doing and make all sorts of weird decisions that are not what you want.

I believe LLMs are going to make the bar for a SaaS you would pay for, as a company, higher.

That's why I assume it goes through support. A support person checks if the prompt is reasonable (and maybe rewrites it).

Again, I just don't think that is possible. If you have, even, 100 customers, you're going to have 100 unique code bases? How can a human tell if a prompt is reasonable for a particular codebase? And who is going to train those support people? Who is going to ensure they are adding tests that actually test real and correct things?

Now where's my customized toaster?

Why send a message to support ? Expose the prompt to your customer if all they are doing is just bouncing it.

I’m assuming the company has policies about what changes they can support. If that’s not true then it’s more of a hosting service.

Yeah, it comes down to pricing, and the quality of the bread. If the bread is fine, then things are fine. It's when the bread is a bit moldy or kinda soapy that, y'know what? I'm gonna make my own damn bread. Or if it's priced weird. What am I paying for, really? If I have to pay for weird upgrades, or something else that sticks in my craw, I'd rather do it myself. With software, I can have Claude shit out a thing and post it to GitHub that only does 10% of there existing product, but it's the 10% that I actually use.

"Accountability" is a value on paper, not in reality. The big companies that sell services are not really accountable, and in many cases will bankrupt their customers. See Revlon with SAP. See the Bavaria Colombian brewery, also with SAP. See the 4Hana case, again with SAP. SPAR group from South Africa. See Tesla surviving by cancelling their SAP deployment. It seems I have spotted a pattern here.

Is there any indication that migration to some other ERP system causes trouble less often? There is a bunch of conventional wisdom about such migrations that some companies disregard and pay the price. I think #1 is don't customize willy-nilly, you will have to maintain those changes forever.

Good article. Appreciate the bread (machine) analogy.

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…

The threat to SaaS is moreso consolidation than AI. Since people value convenience more than anything, having more functionality in one service rather than multiple services will win. For example GitHub integrating more and more code scanning/security functionality rather than having a separate service like Snyk for that.

"Gentlemen, there’s only two ways I know of to make money: bundling and unbundling."

I've made my own bread for many years now. Every other day I make a loaf. Whenever I do buy one, even from a nice bakery, I'm disappointed and my kids hassle me to make it instead of buying.

It's not really relevant to the story though. Bread machines don't make great bread, although they can knead well so when I didn't have much money I'd buy a used bread machine as a mixer.

This breaks the analogy, but I think making your own is more convenient if you meet certain criteria: work from home and have learnt how to do it (ie past the learning phase). It doesn't take much time, but you need to be around. You can make the exact size and type your family prefers. You can make a pizza dough too just whenever you fancy a nice pizza.

I would disagree, but before let me acknowledge how well written article is and bread analogy is spot on. However, author complete discounted open source and ability to spin up open source software that will replicate almost 1:1 what SaaS offers without a pay-to-access requirement. Why spend thousands on integration with SaaS that you can take open source, vibe code missing features and start using? You say maintenance, but I'd argue that owning your data is more important that costs of maintenance. Like bread, when you learn and have ability to choose healthier product you never go back to store brought.

No. You should know that most software are developed for business. Free or too cheap is not good for business use. When I earn money or save money by a software, i can pay it to get full support.

Do you pay for support for all the FOSS you use?

Personally, no. At work, when I can manage it yes. Why else do people pay for RHEL?

This has been true for years already though - why would anyone use confluent over just running Kafka themselves, or self host sentry, elasticsearch, gitlab, mongo, databricks or grafana?

1. Because there were no "free" support, unlike now GPTs can solve most problems without hiring expensive staff. 2. Companies payed millions on trainings specific to their solutions.

If you were running a startup that had at least 1 paid developer, the cost of outsourcing these services were a rounding error compared to the actual salaries. If you wanted to skimp on these other things, you'd be saving maybe 2% of your budget.

Now, these supporting services can quickly become more expensive than the cost of a subscription to a powerful coding agent. You can get a beefy server on Hetzner for less than $50/month, self-host all of that and run entirely on open source alternatives. This is on the same order of magnitude as the cost of your LLM subscription. You can (theoretically) have your whole IT operations costing you a few hundred bucks per month.

The bread analogy is more corrct that they let on. The whole article without the C word.

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.

The classic arc of internal tooling is generally:

* Person gets angry/frustrated/passionate about some third party tool they could build themselves.

* Person builds that tool. It's not perfect but does what company needs (for now)

* Person gets slaps on the back and congratulations for building such an awesome tool and saving the company loads of money

* Person leaves company

* Nobody else cares anymore and/or wants to bother with the inconvenience of keeping up with bugs and features

* After dealing with this for a period of time, someone says "Hey, why don't we just use third party tool?"

* Company re-subscribes to third party tool

Many such examples with variations

- 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 was building an in-house infra management platform (including a self hosted AI agent) for companies in a segment that's very careful about its internal IP.

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.

She's right about Saas. But breadmakers are not an example that land for me.

Breadmaker bread is cheaper, healthier, fresher, and more convenient in every way. I don't always eat bread for breakfast. If I want it tomorrow I have to remember to drive to the store today, costing me at least 15 minutes. Or I can spend 5 minutes setting up the machine before bedtime, and wake up to the smell of fresh bread.

Yes, but the market prefers store bought bread despite the fact that homemade bread is: cheaper, tastes better, and nutritionally better. That's the exact point. Homemade bread should objectively win but it doesn't!

She says store-bought bread wins on convenience, just like SaaS apps. I'm making the case that, actually, it does not - even leaving aside freshness and quality and health.

Her unused breadmaker may be indicative of a skill issue or a more general disinterest in meal planning. Nothing wrong with that. It's just not an apt analogy (for me).

There's really nothing new in this article - but it's all true.

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.

I think there's a secondary competitor to certain types of process-SaaS like Vanta for smaller orgs: a smart Fractional (CISO, in the compliance case) paired with good AI. The purchaser gets proper human judgement, and you can handle the record-keeping bit with an ai-enabled DB like notion.

Ignoring the bread analogy, isn't decoupling a likely outcome? I make and deploy my own SaaS and pay somebody to be on-call for ongoing maintenance. This would argue for more standard interfaces and modules so that maintenance is cheap.

Great article. This last year I've been travelling around and have met 2 people running very lucrative vibe coding agencies. They vibe code websites and apps on behalf of people for whom writing prompts is too much mental overhead.

SaaS is not doomed but their margins are is my bet. They will have to run lean and mean and keep costs under tight control because companies will not be willing to pay for the large margins the SaaS companies enjoyed until recently

The thing about the SaaSpocalypse is not that anyone's going to build their own software - it's that any successful software will have infinite competitors cause there's 0 moat in code.

Great points. Convenience comes first, especially for things not in your core product offerings.

The math has changed for sure, but there is still a large open space in the convenience vs cost equation.

All these arguments ignore that the bread you buy today is not always the bread you’ll get years from now.

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.

I might imagine that even this cycle could change, if the resources necessary to support step 1 and step 2 are much lower. Which might mean step 3 isn’t as necessity driven.

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.

Very true, but if the company has raised VC funds, step 3 is inevitable. Even if the original founder resists making the product worse, the future execs won't blink an eye.

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.

Platform decay is real.

I have relatives who share sourdough starter yeast and make their own bread.

Yes this collective shared knowledge, akin to what open-source provides for software, will always win in the long run

That's more the fate of consumer services though, where the product is typically given away for free and the need for revenues and growth eventually leads to the enshittification you describe. TFA is about SaaS products, which tend to be subscription-based and so usually are immune from those pressures.

SaaS products do have their own problems sometimes, such as feature creep and bloat and uptime, but those are less insidious.

I disagree, business SaaS also gets enshittified mainly because of feature creep like you mentioned. Business SaaS starts by solving problems for 1 type of business, but as they try to cover more use cases, the product gets worse for the original use-case.

This ignores the fact that the bread is poisoned.

I think customers stay with SaaS not just because of the software, but because they trust someone else to handle the complexity.

What an excellent read. It absolutely nails the "why aren't everybody writing software now" question.

My takeaway: I should buy a bread machine.

Also the margins in SaaS used to be 60%; I think for bread its much lower than that.

> "the sound of scared SAAS companies screeching in the distance"

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...

Convenience is the single greatest drug of our species, for better and worse.

The reason why people don't get it has to do with the sorry state of neoclassical economics with its absurd assumption of perfectly divisible goods and how all the skills are averaged into every worker (everyone is a 2% software developer rather than 2% of the population being a software developer).

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.

On another note, we have a similar bread machine. We bake bread multiple times a week. Costs about 10%, takes about 5 minutes to add the ingredients and set. Most times we set it before bed and wake up to the smell of fresh bread and get to eat hot bread. We are 100% certain of the ingredients. We bake different types and when we have a guest, we give them a parting gift of a fresh bread. Our constant baking and the ease has convinced extended family members to do the same. So, I'm not convinced that convenience always wins. If 20-40% of SaaS are replaced with homegrown AI, that is roughly the definition of "doomed" in a market.

Never hurts to have a reasonable, non-alarmist take on why the status quo is probably more durable than the hype men would have you believe. More of this please.

Most AI is SaaS, so in a way this whole argument is circular. It's just one SaaS product gobbling up some other ones.

That said, "White Bread" is a fun book about the enshittification (not using that word lightly) of bread: https://biblioreads.eu.org/book/show/13122087-white-bread

A lot of what the article describes about SaaS is also in the book: the convenience, the standardization, the offloading of time, etc. The article doesn't really talk about the rot that has been going on in the SaaS realm though while the parallels in "White Bread" do.

The article talks about the high standards of bread making in the 12th century and then fast-forwards to the 1960s with a brief stop in 1928 to celebrate slicing tech. It leaves out the dangerous working conditions, the poisonous additives used to save money on bread and the cut-throat competition between U.S. bread companies that spurred those things on. Even ad campaigns that (much like this article) belittled baking bread yourself. Those same things are going on in the SaaS industry, but with software instead of food.

So why do people buy their bread and use SaaS?

> because it was easier, because it was consistent, and because the alternative cost time and attention they’d rather have spent elsewhere.

And just look at where we're spending that time and attention. Maybe it's different for businesses, but consumers are more miserable than ever because they rent garbage and eat bread where high-fructose-corn-syrup is the third ingredient.

> I think the SaaS companies that survive will be the ones that understand they sell convenience and accountability.

I think we've seen, whether that's with our phones (now basically a SaaS platform), our news, our health care, or our entertainment that convenience is enough. Accountability still counts for some b2b SaaS platforms, but the reason why the largest ones have so many lawyers is to get out of that accountability every time they can. And they do.

So yeah I guess I'm depressed that the article is mostly right. I think where it diverges though is that AI has helped me bake a lot more of my own software. It has put me in a place where I spend more time and attention on quality deliverables than I have before. It's too bad SaaS in its current form won't die, the same way it's sad that people are so caught up in their virtual lives that they won't bake a little of their own bread, especially when there's a convenient machine sitting on their counter ready to go.

Yet I bake my own bread because the "bread" you can buy isn't bread.

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

Reply on news.ycombinator.com