Every few weeks, another post appears in my feed declaring that SaaS is finished.
Someone cancelled a subscription, vibe-coded a replacement in an afternoon, and now the economics of software are apparently solved. Why pay €30, €300, or €3,000 a month for a tool when an AI can generate the same thing with a prompt?
The story has become loud enough that it has started leaking into financial markets. Investors are suddenly trying to understand what AI-assisted software creation might do to companies like HubSpot, Adobe, and Salesforce. If every company can build its own tools now, what happens to the companies that sell them?
That anxiety has shown up in analyst commentary and stock volatility. Not because SaaS is suddenly obsolete, but because markets are trying to price a new uncertainty: if software becomes dramatically easier to build, what exactly are customers paying for?
I understand the excitement. I’ve been experimenting with the same tools.
Over the past months I’ve spent close to 1000 hours vibe coding different projects. About 80 percent of that time went into commercial initiatives. Not hobby experiments. Real work for clients, internal tools I wanted to use, systems that needed to behave predictably when someone other than me clicked a button.
The productivity jump is real. Sometimes almost suspiciously real, but the screenshots circulating online usually stop at the moment where the demo works.
That is where the interesting part actually begins.
The demo moment
Recently I built a simple consent management platform while live streaming on Youtube.
Nothing revolutionary. A cookie banner. Preference settings. Google Consent Mode logic. A small admin interface. A script that could be injected into a website.
Within a surprisingly short amount of time the thing actually worked. It pushed events into a data layer, showed a banner, stored preferences, and allowed configuration through a small interface.
A few years ago that kind of prototype would have taken a very different setup. Possibly a small development team. Definitely more planning.
So yes, the productivity gains are real.
But that CMP project was mostly a demonstration. A small iceberg tip to show what sits behind the idea of “just build it yourself.”
The real lessons did not come from that demo.
They came from client work and from building my own tools.
One of those tools is the Martech Stack Builder, a project designed to help people design marketing technology architectures and explore vendor combinations. Something that started as a relatively straightforward idea and slowly revealed how many layers sit underneath even a “simple” application.
Projects like that teach you something quickly.
Software is rarely just code.
It is architecture decisions. Deployment pipelines. Hosting environments. Versioning. State management. Security concerns. Documentation. The quiet pile of operational details that nobody includes in their triumphant “I replaced SaaS with a prompt” screenshot.
That is where you start developing respect for complexity.
Buying software means buying distance from the mess
Buying software often looks expensive on paper. Monthly subscriptions. Usage tiers. Enterprise pricing that makes procurement teams sigh. But those invoices buy something important.
Distance
When you buy software you are paying someone else to worry about uptime monitoring, infrastructure, security patches, scaling issues, and the strange edge cases that appear when real users interact with a system in ways the designers never anticipated.
You are also buying a hotline.
When something breaks, you call someone else.
You invoke the SLA. Someone on the other side of the contract now owns the problem.
From the outside it looks like you are buying features.
In reality you are outsourcing responsibility.
Building means you become the hotline
The moment you decide to build your own tool, that responsibility moves back across the table. Back to yourself.
Suddenly you are the one thinking about hosting environments, authentication methods, deployment pipelines, environment variables, configuration storage, and backups.
If something breaks on a Sunday evening, there is no support ticket to open.
You are the support team.
You serve your own SLA.
None of that responsibility disappears because AI generated the first version faster. It simply arrives earlier in the lifecycle.
This is where many of the “AI replaces SaaS” narratives quietly lose their momentum and reality, for many sinks in. The prototype exists, but running it properly requires a different level of commitment.
And that commitment grows as the tool becomes more useful.
Why companies still want to build
There is an important counterargument here.
Buying software has real limitations.
Off-the-shelf tools are designed for broad markets. That means compromise. Workflows that almost match your business process but not quite. Features that cover eighty percent of what you need while ignoring the twenty percent that actually differentiates your organization.
In marketing technology this problem shows up everywhere.
Forms that cannot validate exactly the way you want. Routing logic that almost fits your customer journey but stops just short. Data models that push your operations into shapes that make sense for the vendor’s roadmap rather than your own.
This is where building becomes attractive.
When you control the system, you can design tools that fit your workflow instead of bending your workflow around the tool.
Scott Brinker has described this phenomenon as the rise of internal micro-SaaS. Small specialized applications built to serve specific organizational needs.
That flexibility is the real prize.
Not the thrill of cancelling a subscription.
The ability to build something that actually fits.
The thousand-hour reality check
After roughly a thousand hours experimenting with vibe coding, one thing has become clear.
The balance point between buying and building is not obvious.
Sometimes building a tool feels liberating. You solve a problem exactly the way you want. The system behaves precisely according to your rules.
Other times you slowly realize that you have created a new responsibility for yourself. A system that now requires monitoring, small improvements, occasional debugging, and the kind of maintenance work that nobody celebrates.
That moment usually arrives quietly.
The first version works beautifully.
The second version requires a deployment tweak.
The third version introduces authentication.
The fourth version needs configuration storage.
And somewhere around version five you start thinking about databases, audit trails, and how many evenings you would like to donate to infrastructure management.
The flexibility is real.
The freedom is real.
But the operational gravity is real too.
The new middle layer: SaaS for building SaaS
Interestingly, the industry is already responding to this tension.
Platforms like Lovable and Replit represent a new layer in the ecosystem.
They are essentially SaaS wrappers around vibe coding.
They provide development environments, hosting infrastructure, deployment pipelines, and collaboration features. In other words, they temporarily remove much of the operational burden that comes with building software.
These tools are fantastic starting points.
You can experiment quickly without worrying about infrastructure.
But they may also have a natural shelf life.
As projects mature, teams often want more control over architecture, hosting environments, security policies, and cost structures. That is when many projects move beyond the wrapper and back into self-managed infrastructure.
Which is an interesting twist.
SaaS might not disappear.
It might simply evolve into a different role.
Instead of selling finished applications, some SaaS companies may end up selling development environments, orchestration layers, and infrastructure platforms.
The skill that will matter most
This shift also changes which skills matter.
As Guy Royse observed, based on a video from Nate B. Jones:
“It will come down to the ability to define what the code should do.”
AI can generate code.
But someone still needs to define the problem, design the architecture, anticipate edge cases, and decide how the system should behave when reality inevitably refuses to follow the happy path.
That skill set looks less like traditional programming and more like system design combined with domain expertise.
Martech raises the stakes
In marketing technology the consequences of these decisions are amplified.
Many Martech tools sit close to sensitive systems:
consent management, identity resolution, attribution logic, campaign orchestration, customer data flows.
When something breaks in those areas, the consequences can be more than inconvenient. Compliance risks appear. Tracking breaks. Leads disappear. Reporting becomes unreliable.
That is why the build versus buy decision in Martech tends to carry more weight than in many other software categories.
The uncomfortable conclusion
Vibe coding is real
It will absolutely change how software gets built. It lowers the barrier to experimentation, shortens the path from idea to prototype, and enables companies to create tools that would have been unrealistic only a few years ago.
But the economics of software have not disappeared.
They have moved.
Buying software often means paying someone else to carry the operational weight. Infrastructure, monitoring, security patches, uptime guarantees, and the long tail of small issues that quietly accumulate in any system.
Building gives you freedom.
The freedom to design tools that actually fit your business instead of bending your business around someone else’s roadmap. The freedom to create internal micro-SaaS solutions that solve very specific problems. The freedom to move faster when the standard tools fall short.
It also hands you the pager.
Sometimes that trade-off is exactly what you want. Flexibility and control can be powerful advantages when they are used deliberately.
But the economics of software haven’t been broken.
They’ve just been rearranged.
Start building your Martech Stack designs today 👇🏻
Discussion