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?
The bread paradox: why convenience always wins, and why SaaS isn't doomed
51–60 of 127 posts
Re: The bread paradox: why convenience always wins, and why SaaS isn't doomed
#52I 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…
Re: The bread paradox: why convenience always wins, and why SaaS isn't doomed
#53Since 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
#54Earlier 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…
be the change
Re: The bread paradox: why convenience always wins, and why SaaS isn't doomed
#55The 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…
Re: The bread paradox: why convenience always wins, and why SaaS isn't doomed
#56The 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…
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
#57One 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
#58Conventional 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
#59The 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…
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
#60This 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.