I keep seeing the same confident line about vibe coding.

"I can build that."

"That SaaS tool is dead."

"Why would I pay for this when I can get an agent to make it?"

And in one way, I agree with the pressure behind it.

A lot of SaaS pricing is going to have to change. The old seat-based model is under pressure. The idea that a company should pay hundreds of thousands, or even millions, each year for tools that mostly store records, enforce workflows, and wrap business logic in screens is going to be challenged very hard.

Agents change the buy-vs-build equation.

MCP changes it.

A2A changes it.

AI app builders change it.

But there is a missing cost in a lot of the conversation.

Human time.

Human effort.

Human attention.

Human responsibility.

Vibe coding may make the code cheap.

It does not make the system free.

This is a follow-on to Vibe Coding Is Not The Problem. That piece was about maturity and judgement. This one is about the cost line that gets missed: human time and operating responsibility.

The visible price is not the real price

When you buy SaaS, you see the subscription.

It is easy to hate that number.

It sits there on the budget line. It renews. It creeps up. It adds seats. It adds modules. It adds implementation partners. It becomes one of those things everyone complains about but nobody wants to unplug because some important process now depends on it.

So the new temptation is obvious.

If I can vibe-code the workflow in an afternoon, why am I paying for the product?

That is a fair question.

But the comparison has to be honest.

If you spend an hour building something, that hour has a cost.

Not just your salary.

Your fully loaded cost.

National insurance. Pension. Desk. Laptop. Software. Management. Heating. Office. Security. The opportunity cost of not doing the thing you were meant to be doing instead.

And then there is the second cost.

What happens after it works?

Disposable code is different

I have no problem with disposable code.

In fact, I love it.

Build a quick tool to clean a file.

Generate a one-off dashboard.

Create a script to explore an idea.

Make a personal helper that saves you twenty minutes today.

That is brilliant.

That is exactly where vibe coding shines.

You create it. You use it. You throw it away. Or you keep it in your own little workspace with no expectation that the rest of the business now depends on it.

The problem starts when the thing crosses the line.

Someone else uses it.

A team relies on it.

It stores customer data.

It touches money.

It sends emails.

It changes records.

It becomes part of the way the company works.

At that moment, it is no longer just a clever little tool.

It is an operational asset.

And operational assets need owners.

Infographic showing visible and hidden costs of vibe coding, with a decision line between disposable tools and shared operational systems.
The app may be cheap to create. The system still needs someone to own the responsibility around it.

What SaaS was quietly doing for you

It is fashionable to sneer at SaaS now.

Some of that is deserved.

Too many products have charged enterprise prices for workflows that feel slow, rigid, and overbuilt. Too many products have made people click through screens that exist mainly because the software was designed around tables and permissions rather than human intention.

I have written about that before in Release Us From The Tyranny Of The Wizard.

But we should be careful.

SaaS was not only selling screens.

It was also selling maintenance.

Support.

Uptime.

Backups.

Security patches.

Access control.

Audit trails.

Documentation.

Permission models.

Integration surfaces.

A shared language for the business.

That last part matters. In Sharing Is A Language, I argued that SaaS systems do not only store data. A CRM gives people a shared meaning for customer, opportunity, owner, stage, next action, and loss reason. An ERP gives people a shared meaning for stock, order, invoice, commitment, available quantity, and fulfilment.

When you replace a SaaS system with something you vibe-coded, you do not just replace the screens.

You inherit the language, the rules, and the responsibility.

The "SaaS is dead" story is too simple

I do think SaaS has to reinvent itself.

Bain has framed the agentic AI disruption of SaaS as mandatory disruption but optional obsolescence. That feels about right. Deloitte expects AI agents to grow through SaaS applications rather than simply remove them overnight. TechRadar's recent "SaaSpocalypse" framing reaches a similar place: SaaS is not dead, but weaker models and lazy pricing will be exposed.

The Satya Nadella line that gets repeated is that many business applications are basically CRUD databases with business logic, and that agents may collapse some of that application layer. I think that is directionally important.

But the wrong conclusion is:

"Therefore we can delete SaaS and vibe-code everything."

The better conclusion is:

"The value is moving."

It moves away from screens for the sake of screens.

It moves away from charging people to click buttons.

It moves toward data integrity, source authority, workflow truth, policy, governance, audit, interoperability, and agent-readable control surfaces.

The best SaaS companies will become language layers, governance layers, and agent-ready infrastructure.

The weakest SaaS companies will discover that a lot of their value was only the fact that building software used to be hard.

That is also why I keep coming back to agentic interfaces. If a system cannot be used by agents safely, it starts to feel less like infrastructure and more like a place designed to consume attention.

The hidden bill

There is already a growing body of commentary about the hidden cost of vibe coding.

Some of it is overdramatic, because the internet is the internet.

But the categories are real.

Rework.

Token burn.

Security remediation.

Technical debt.

Testing.

Deployment.

Edge cases.

Design sameness.

Broken happy-path interfaces.

Tools like Lovable, Bolt, Replit, Cursor, Claude Code, and Codex are getting better quickly. They are not toys. But the important question is not whether they can produce an app.

They can.

The important question is what happens when the app matters.

That is where engineering returns. In Engineers Are Not Just People Who Write Code, I make the same point from the other side: the code is visible, but the system around the code is where the real responsibility lives.

Who updates it?

Who patches it?

Who checks the dependencies?

Who reviews the permissions?

Who restores it if the data is corrupted?

Who explains the audit trail?

Who makes sure the thing the user intended is the thing that actually happened?

If the answer is "nobody", the app was not cheap.

It was just underpriced.

Intent needs a new surface

This is where I think the conversation gets more interesting.

I do not think the answer is to go back to old wizard screens and browser forms.

I do not want more menu trees.

I do not want more dashboards that exist because a database table needed somewhere to live.

I think we will move toward intent surfaces.

A person says what they are trying to achieve.

An agent translates that intent into the shared language of the business.

An MCP exposes the right tools or data.

A2A lets specialist agents coordinate where needed.

The system shows what it understood, what it will change, what evidence it used, what risk it sees, and what approval is needed.

Then the action becomes auditable.

That is the bit I care about.

Not just "did the agent click the button?"

But "was this actually what I intended?"

Because in real business life, 80 percent fit is often good enough.

But sometimes the missing 20 percent is where the legal, financial, customer, or operational problem lives.

The ownership test

So here is the practical test I would use.

Before you vibe-code a replacement for a SaaS tool, ask:

Is this disposable?

Is this personal?

Does it touch private data?

Does anyone else rely on it?

Does it change records?

Does it send anything externally?

Does it need to be backed up?

Can it be restored?

Who maintains it?

Who checks whether it is still correct in six months?

Who pays the human time bill?

And the killer question:

Do you want to own this system?

If the answer is yes, brilliant. Build it properly. Use agents. Use MCP. Use A2A where it makes sense. Use the AI tools. Make it better than the thing you were buying.

If the answer is no, maybe the SaaS subscription was not as expensive as it looked.

The practical line

Vibe coding is not free.

That does not make it bad.

It makes it real.

It is a huge productivity shift for disposable tools, personal workflows, prototypes, exploration, and smart internal experiments.

It will absolutely put pressure on SaaS pricing.

It will absolutely create bespoke workflows that would never have justified traditional software development.

It will absolutely change what companies buy and what they build.

But when the tool becomes a system, the responsibility arrives.

The code may be cheap.

The ownership is not.

Sources and notes

This is a researched opinion piece. I am not arguing that SaaS is dead, or that vibe coding is bad. I am arguing that the economics have changed, and that the real comparison must include human time, maintenance, security, data, audit, and ownership.