Live data from Hacker News

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

joanwestenberg.com

51–60 of 127 posts

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

#51

Earlier quoted context omitted.

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?

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

#52

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 maintenan…

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?

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

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

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

#54

Earlier quoted context omitted.

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 industri…

just do it!

be the change

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

#55

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…

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.

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

#56
post #47

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

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…

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

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

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

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

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

#59

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…

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.

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

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

Post reply on HN