Beyond Vibe Coding — Vol. 3　Defining the Era Beyond Vibe Coding

The Question Nobody Asks Before They Build

There is a question that has shaped the entire history of enterprise software.

It isn't "can we build this?" It isn't "how fast can we ship?" It isn't even "will users want this?"

It's simpler and more uncomfortable than any of those:

Who maintains this? At what cost? For how long?

Every major shift in how businesses use software — from mainframes to packaged software, from client-server to cloud, from on-premise to SaaS — has been, at its core, an answer to that question. Not a technical answer. An economic and organizational one.

If you're building with AI right now and you haven't asked it yet, this post is for you.

The History Nobody Teaches

The Mainframe Era: Build Everything

In the early decades of commercial computing, large organizations built their own systems. Custom logic, custom interfaces, custom everything. The in-house development team was a source of competitive pride.

Then those systems aged. The developers who built them moved on or retired. The institutional knowledge of why the code worked the way it did — the undocumented decisions, the workarounds, the tribal knowledge — began to disappear. What remained were systems that no one fully understood, that everyone depended on, and that cost a fortune to keep alive.

The lesson: the cost to build is one-time. The cost to maintain is forever.

The Package Software Era: Buy Instead of Build

The market responded. Why build a payroll system from scratch when you could buy one? Why maintain custom accounting logic when SAP would do it — and handle the regulatory updates, and provide support, and employ the people who understood it?

SAP, Oracle, and their peers didn't win because their software was elegant. They won because they absorbed the maintenance burden. They employed armies of people so that their customers didn't have to.

The lesson: if someone else can own the operational complexity, let them.

The Client-Server Era: Build Again, Regret Again

Then the PC revolution made distributed computing feel possible and exciting. Organizations built rich client applications, complex server logic, elaborate integrations. IT departments grew. Deployment became a project. Updates required coordinated rollouts across hundreds of machines.

Operations teams aged a decade in five years.

The lesson: complexity compounds. What seems manageable at v1 becomes a different problem at v3.

The Cloud and SaaS Era: Back to Letting Go

Again, the market responded. Run it in the cloud. Subscribe to the service. Let someone else handle the uptime, the security patches, the infrastructure scaling, the compliance certifications.

SaaS didn't win on features. It won on the answer to the maintenance question: not your problem anymore.

"SaaS Is Dead." Is It?

There's a narrative gaining momentum right now: AI has changed the economics of software development so dramatically that the SaaS model is obsolete. Why pay a monthly subscription when you can build a custom solution with AI in a weekend?

I understand the excitement. The cost to build has genuinely dropped. Tasks that once required a team now require a prompt and some patience.

But look at that history again.

Every "build it yourself" wave eventually collided with the same wall. Not at launch. Not at v1. Months or years later, when the original builder has moved on, when requirements have changed, when a critical bug appears at 2am and nobody remembers how the system works.

AI lowered the cost to build. It did not lower the cost to maintain.

Bugs still need fixing. Requirements still change. Integrations still break when the upstream API changes. Data migrations still go wrong. Security vulnerabilities still need patching. And all of that still requires someone who understands the system — at whatever cost that person commands, for as long as the system runs.

The maintenance question didn't go away. It just got deferred.

The Right Scale for AI-Built Products

I want to be precise here, because I'm not arguing against building.

I built IFRS-OneQ with AI. I think more domain experts should build with AI. The opportunity is real.

But there is a meaningful difference between two types of projects:

Projects you can own indefinitely — where you are the maintainer, you understand the full system, the scope is bounded, and you can take personal responsibility for what happens when things break. This is where AI-assisted development is genuinely transformative. One person with domain expertise and AI tools can now build and maintain something that would have required a team five years ago.

Projects that will outlive your involvement — business systems that dozens or hundreds of people depend on, that need to run reliably for years, that will require updates as regulations change and teams grow and the original builder moves on. Here, the maintenance question becomes an organizational question. Who owns this? Who has the budget to maintain it? Who gets the 2am call?

The first category: build freely. The second: think carefully before you convince yourself that AI has changed the answer.

Most of the "SaaS is dead, build everything with AI" conversation is conflating these two categories. The economics of the first have changed dramatically. The economics of the second have changed less than people think.

The Question Before You Start

If you're about to build something with AI — whether for yourself, your team, or your customers — sit with these questions before you write the first prompt:

Is this something I can maintain personally, indefinitely?

If not, who will maintain it — and do they know that yet?

What happens when I'm no longer available?

What is the true cost of ownership over three years, not just the cost to build?

These aren't questions designed to stop you from building. They're the questions that separate a product from a prototype. They're the questions that every enterprise software decision — across seventy years of industry history — has eventually been forced to answer.

AI made building cheaper. It didn't make the questions go away.

Ask them first.

The Hidden Cost of FDE

AI has made building cheaper, and something has finally started to shift. Developers are going into the field — watching how work actually gets done, picking up problems on the ground, and building solutions on the spot. This is what people are calling FDE: Field-Driven Engineering.

Honestly, this should have become standard practice much earlier. Imagining requirements in a conference room is no substitute for watching real work happen in real environments. Building from reality, not from specification documents — that is a genuine step forward.

So yes, go to the field. See it, hear it, build it. In the age of AI, there is no excuse not to.

But there is something you need to think about at the same time as you build.

Who maintains this after you leave? Can it be handed to the next customer? Will it still exist once you are no longer involved?

Building in the field is right. The problem is treating what you built there as something that only needed to exist in that moment.

When you build quickly in the field, value appears fast. It gets used. And because it gets used, it stays.

If it stays — it is already a product.

Which means you needed to be thinking from the start: how will this be maintained? How much can be shared across customers? How do you hand this to the next company?

That has to be part of the thinking while you build — not after.

FDE accelerates customer understanding. It does not eliminate maintenance responsibility.

Go to the field. I say this as someone who spent a career doing exactly that — I can say it with confidence. But on the question of maintenance responsibility, learn from history before you find out the hard way.

What I built — as one person

→ IFRS-OneQ — Multilingual IFRS education app, live on Google Play & Web: ifrs-labo.com/posts/ifrs-oneq

→ IFRS Deep Dive — Newsletter with readers in 30+ countries: Subscribe on LinkedIn

→ IFRS-LABO — The company behind both, built from scratch: ifrs-labo.com

I started each of these only after confirming that I could sustain them.

Conclusion

We have entered an era where anyone can build. That is a reality.

As I discussed in Vol. 1, the judgment to decide what to build is something AI cannot replace. As explored in Vol. 2, the design eye—knowing what to feed the AI and, more importantly, what not to—must remain a human skill. And as written here in Vol. 3, the responsibility for what is built cannot be offloaded to AI; it remains with the individual or the organization.

Competing over hardware specs, polishing prompts, and testing the latest models is exciting and has its place.

However, the ability to build is distinct from having something worth building. If you have something worth building, you must also answer the question: who will carry the responsibility for it until the end?

Enthusiasm is a powerful engine for progress. But enthusiasm without an understanding of history will inevitably hit the same walls as its predecessors.

Beyond Vibe Coding means building with the full awareness of where those walls are.