There’s been a lot of news about the latest LLMs focused on coding. One thing that is clear in practice is that code is, for the most part, cheap now.

The issue that most analysts, including AI analysts, continue to miss is that code has never been the issue in software. It was always a barrier to entry, and a pretty expensive and complicated at that.

Saying that now that you can build it, you’ll be able to dethrone any established SaaS player is simply a pipe dream.

The feature trap

Most people who have never started a business think that building the software is the most important part. As part of our consulting business, we have seen many of our clients believe that adding one more feature, or ensuring we have all the bells and whistles in their software product, will guarantee customers will sign up immediately. They spend months, and sometimes years, trying to come up with the perfect design, the perfect set of buttons and text boxes, to launch a product.

But the sad reality is that we have seen Excel spreadsheets succeed just as much as a full-fledged application in the first, and usually the most difficult part of a product's life, which is simply the first customer acquisition.

Nevertheless, what being able to produce features cheaply enables is experimentation. Experimentation and quick iterations of product features can help you achieve (or rather, find) a stronger market fit.

The top code quality trap

A bunch of engineers will disagree with me on this one. Having top-notch code quality, perfect code, doesn’t matter.

And, for my fellow engineers, answer only one question: are all products out there perfect? How many of those products are not defective in one way or another? How many of those products have “top-notch “ quality as perceived by their end users? How many of them are free of issues?

I am not saying code quality does not matter. There is obviously a minimum bar you must meet to actually have a functional product. The key is that it isn’t necessary for success. It makes it easier, sure.

Market fit is everything

The most important thing in software is market-fit. Once you have market fit, and depending on how strong it is, you can expect some level of success.

Market fit is simply the extent to which your solution meets your expected market's needs. If you found a market that strongly needs what you are selling, you could sell an Excel spreadsheet, and the market would buy it.

What I am saying is that market fit pulls people in and marketing creates reach, not code. You can build an amazing piece of software, but if it doesn’t meet market needs, it will never sell.

As your market fit decreases, you need to do more. More marketing, more pushing, more convincing, and sometimes, more software. But don’t be fooled, what matters is market fit and your ability to design something that matches. Deciding not to build a feature is as hard as, if not harder than, deciding to build it.

Why SaaS won’t die: trust

SaaS won’t die because companies learned long ago that specialization is beneficial. There is no reason for a company to build an ERP from scratch (even if they could, or even if their problem was that it was expensive to code). No sane CIO would choose to replace their proven GL software with an internally built system. Opportunity costs matter, and matter a lot.

There is no way a global manufacturing company will develop its own inventory management software from scratch just because Claude Code can produce a basic version in a few weeks.

SaaS is not only about the product; it is also about trust. No matter how experienced your internal accounting team is, they are probably not savvy on the intricacies of how to design double-entry ledgers efficiently (and if you don’t believe me, even established ERPs show that their initial designs were flawed).

The key is that when you can’t differentiate through features (because any feature can be built at near-zero cost), trust and judgment become even stronger differentiators.

But SaaS will change

Even though SaaS won’t disappear, it will change - and there will be a huge window of opportunity where established players have weaker market fit.

Generally speaking, the small and mid-market segments tend to have lower switching costs than the enterprise market. In these segments, new players who can find a stronger fit by offering cheaper products, niche features, and specialized verticals will succeed in slowing enterprise SaaS growth.

Smaller firms will find that building exactly what they need is cheaper than renting SaaS for specific niches within their industries. However, it is unlikely to unseat established players in already settled business areas such as CRM, accounting, HRIS, inventory management, retail, and others.

The big opportunity is to identify the gaps between all those solutions and established SaaS offerings, and to quickly fill them. Just don’t expect Salesforce to be dethroned tomorrow.

The big question is how incumbents respond. They have distribution, capital, and customer trust. They can build most of these “gap fillers” themselves if they decide the gap is worth defending. The problem is incentives. Incumbents rarely want to disrupt their own pricing model until someone else forces them to.

Enterprise SaaS will still face pricing pressure. When code is cheap, the breadth of features stops being a convincing reason to raise prices. The defensible ground shifts to what customers cannot casually recreate: reliability, compliance, operational depth, and accountability. Agentic AI will make many SaaS surfaces feel thinner or even unnecessary, but the underlying workflows do not disappear. If incumbents want to keep pricing power, they need to own the workflow and the system of record, not just the interface. Otherwise, they will default to the weakest defense: raising switching costs through lock-in tactics, such as charging high fees just to access your own data (as some already do).

The SaaS Conundrum

Code is cheap, and it will keep getting cheaper. That does not mean SaaS is over. It means the easiest part of software has gotten easier, and the hard part has stayed the same: finding a market that cares, earning the right to handle real workflows, and getting people to trust you with the ugly parts of their business.

So the winners will not be the teams that ship the most features. They will be the teams who can say “no” to most features, ship the few that create real pull, and get distribution fast. In the small and mid-market, that pull can come from niche depth, a better price-to-value ratio, and faster iteration. In the enterprise, it will come from trust, compliance, reliability, and switching costs that are rooted in outcomes, not lock-in games.

For incumbents, the risk is not that a competitor will rebuild its UI with an agent. The risk is that customers will stop paying for feature breadth when AI can glue together “good enough” alternatives. The defense is not more buttons. The defense is becoming the system that owns the workflow, the data model, and the accountability.

That’s the SaaS conundrum in the LLM era: you can build almost anything now, but you still cannot manufacture trust, distribution, or market pull. You have to earn those the old-fashioned way.