We are currently going through one of the biggest technological paradigm shifts in history. And this makes me think that a lot of companies will be facing the same difficult decisions as Kodak did some decades ago - “should we go for this digital photo thing, or put more investments into what is currently making us money - analog photo?”.
I do not think large SaaS companies will completely disappear because agentic coding gets better. But some actors will struggle to adapt.
Small, medium or large companies will not suddenly stop buying ERP, payroll software or similar heavy law and policy adapted solutions overnight.
I have worked hands-on with building, implementing, and selling ERP and payroll software. That experience makes me careful about claiming that these categories are easy to replace. They are not.
Compliance is real. Integrations are real. Organizational risk is real. Vendor accountability is real. Maintenance is real.
But that is exactly why the question is interesting.
Even the most defensible SaaS categories will start feeling price pressure over the next years, what does that say about the rest of the market?
Over longer timeframes the pressure might push SaaS to the cost of electricity + infrastructure, but way before that another challenger will and already is arising.
The cost of saying “we could build this ourselves” is falling.
The Old Digital Transformation Bargain
For the last twenty years, the default argument for large SaaS has often been simple:
Building is too slow, too expensive, too risky, and too hard to maintain. Buy the whole solution.
That argument has worked for good reasons.
When internal software teams were small, delivery cycles were slow, and custom software often became expensive internal archaeology, buying a mature platform for certain workflows was rational. The vendor had more developers. The vendor had more product managers. The vendor had support, compliance, operations, sales, partner ecosystems, migration tooling, and a roadmap. But the main point, the vendor could distribute cost of the software development process to many customers.
The customer paid for that machine through subscription pricing.
In return, the customer accepted another cost:
We will adjust parts of our organization to fit the software.
That was the bargain.
The software was not only a tool. It became an operating model.
Sometimes that was good. Standardization can be healthy. Many companies genuinely benefit from cleaning up messy processes, removing local exceptions, and adopting a better workflow.
But sometimes the platform did not represent better work.
Sometimes it represented work that was easier to sell repeatedly.
Large SaaS has to carry a lot of internal cost. Developers, support, compliance, operations, sales, implementation partners, customer success, platform teams, security, marketing, and management all have to be paid by the same recurring product.
That does not make the price unfair by itself.
It explains why the price has to be high.
But it also explains why the model becomes vulnerable when customers gain the ability to build more of the exact software they need internally.
The Price Of “Build” Is Changing
Historically, “build versus buy” often had an obvious answer.
Buying looked expensive, but building looked dangerous.
Building meant:
- hiring enough developers
- finding product leadership
- designing architecture
- writing integrations
- maintaining infrastructure
- handling security
- documenting the system
- fixing bugs forever
- keeping the team alive through organizational changes
For many organizations, buying SaaS was the safer answer even when the fit was imperfect.
Agentic coding does not remove these responsibilities.
But it changes the shape of them.
A small internal team with strong domain knowledge, good engineering judgment, solid reference architectures, and agentic coding tools can now explore, prototype, integrate, and maintain software at a speed that used to require a much larger team.
The important shift is not that AI writes code.
The important shift is that internal teams can turn domain understanding into working software much faster.
That democratizes innovation.
Not in the vague “everyone is a developer now” sense.
In the practical sense that an organization no longer has to choose only between:
buy a large generic platform
or
fund a huge internal software program
There is a new middle path:
build narrower internal capability
around the exact workflows that matter
with agent-assisted software delivery
That middle path is where the pressure on SaaS pricing starts.
Downward price pressure will make competition though for traditional SaaS vendors, and they will need to adapt to please customers and keep profit going.
The Workflow Problem
The deepest problem with generic SaaS is not the cost.
It is the way it shapes work processes at the customer.
People do not only buy software. They buy a set of assumptions about how work should happen.
Those assumptions are built into screens, objects, approval flows, roles, permissions, states, notifications, dashboards, integrations, and reports.
When the assumptions fit, SaaS can feel really good.
When they almost fit, SaaS becomes a negotiation with the product.
When they do not fit, the organization starts bending itself around the tool.
This is where I think traditional digital transformation models are most exposed.
For years, companies have accepted a surprising amount of workflow distortion because the alternative was perceived to be more costly.
The platform had the funding, the developers, the roadmap, the integrations, and the sales narrative. The customer had business knowledge, but often not enough internal software capability to turn that knowledge into durable tools.
So the customer changed the work process instead.
Sometimes that change was ok and maybe even of decent value.
Sometimes it was surrender.
Agentic coding makes that distinction more important.
If a team can build a good internal tool around the workflow as it should be, why should it keep pretending that the workflow must fit a rigid product model?
The New Competitive Advantage
The companies that get good at agentic coding will not only save money.
They will learn faster.
They will be able to ask better questions:
- What parts of our workflow are truly standard?
- What parts are only standard because a vendor made them standard?
- What parts create customer value?
- What parts create employee frustration?
- Which internal tools would give us leverage if they were built around our actual work?
- Which vendor systems should stay, but become smaller pieces in a more intentional architecture?
That last question matters.
Many large systems will remain. Some should remain. Some workflows are commodity. Some need vendor liability. Some are better served by platforms with deep compliance and ecosystems.
Internal workflow tools, decision support, reporting, operations dashboards, integrations, exception handling, onboarding flows, customer-specific processes, data cleanup, and small domain-specific applications are all becoming more buildable.
That is where companies can create an advantage.
Not by trying to rebuild the world.
By learning how to build the pieces that make their own work better.
The SaaS Vendors That Survive
The strongest SaaS vendors will not be the biggest.
They will be the ones that do at least one of these things extremely well:
- match a real niche workflow better than almost anyone else
- provide a platform that is genuinely flexible without becoming chaos
- own a compliance, network, or ecosystem advantage that customers cannot easily reproduce
- become an enabling layer for internal builders instead of a rigid replacement for them
- price in a way that makes sense when customers have credible alternatives
That last point is uncomfortable.
If customers become better at building themselves, large SaaS vendors lose pricing power.
The old comparison was:
expensive SaaS that forced work processes
vs
expensive internal build
The new comparison may become:
expensive SaaS with forced workflows
vs
small internal team with agentic coding capability and tailored workflows
That is a very different negotiation.
The Kodak Trap
The danger for companies is not only buying too much SaaS.
The danger is failing to build the internal capability to know the difference.
This is the Kodak trap as a management pattern.
The problem is not always that leaders cannot see the technology. Often they can. The problem is that the business model, operating model, skills, incentives, and habits do not move fast enough when the technological paradigm shifts hit.
If your organization keeps buying large systems because it has no internal ability to build, integrate, adapt, or challenge them, then the vendor is not just selling you software.
The vendor is also doing a lot of your organizational learning for you.
That is dangerous during a technology shift.
Because the companies that learn internally will start compounding.
They will get better at scoping. Better at architecture. Better at understanding where AI helps and where it does not. Better at turning messy work into software. Better at deciding what should be bought, what should be built, and what should be ignored.
The companies that do not learn will keep outsourcing the learning curve.
The Better Version Of Digital Transformation
The better version of digital transformation is not:
Buy a big platform and transform the organization around it.
It is closer to:
Build the internal capability to understand, improve, and automate your own work.
Sometimes that means buying SaaS.
Sometimes it means building.
Sometimes it means using SaaS as the stable system of record while building internal tools around the workflows that make the company different.
Sometimes it means replacing a broad platform with a narrower tool that fits better.
Sometimes it means doing nothing because the process is not important enough.
The point is agency.
Agentic coding matters because it gives organizations more agency over their own digital shape.
When software gets cheaper to build, the question changes.
It is no longer only:
Which platform should we buy?
It becomes:
Which capabilities should we own?
That is the strategic shift.
My Current Bet
My current bet is that large generic SaaS will face more pressure than most people expect.
The companies that modernize internally will become less willing to pay high prices for rigid software that forces their work into someone else’s model.
The SaaS vendors that keep winning will either fit specific workflows incredibly well, become much more flexible, or provide infrastructure and ecosystem value that internal teams actually want to build on.
The companies that fall behind will keep buying large SaaS because they do not have another credible option.
That may work for a while.
But it is a dangerous place to be.
The next competitive advantage will not come from having access to the same SaaS platform as everyone else.
It will come from having the internal capability to build the tools your organization always needed, around the work as it was meant to happen.