Vibe Coding Is the New Excel (and That's Fine)

A few days ago, Klaas (@forgebitz) posted this on X:

"i have no time to maintain all my vibe coded tools
we need a business model where someone else maintains the code and i just pay a monthly fee"
It's a joke, of course. That business model has existed for more than twenty years, and it's called software as a service. But like every good joke, it says something true: building a tool with AI now takes an afternoon, and keeping it alive takes the rest of its useful life. We have seen what happens to tools like these before, with a different technology.
First, There Was Excel
When spreadsheets showed up, the people who run the business adopted them right away. They didn't need to ask anyone for anything: they built one spreadsheet to track stock, another for commissions, another for the department budget. It simplified their work and solved real problems, on the spot.
Over time, those spreadsheets evolved. They added formulas, macros, linked sheets, data feeding other spreadsheets. Many became essential. And many ended up as the starting point for applications: the day the spreadsheet was no longer enough, someone used it as the specification and built the system that did the same thing, properly.
Spreadsheets were not a mistake. They were how the business expressed what it needed, before someone turned it into software.
Vibe Coding Is the New Excel
Vibe coding is the same thing, at a different scale. Today someone who knows their process well can describe what they need to an AI assistant and, in a short time, have a working application: screens, a database, users.
Many large companies are encouraging this explicitly: they want the people in charge of each area to build their own apps, without waiting for a slot on IT's roadmap. And it makes sense. These apps are useful, they are built by whoever understands the problem best, and productivity goes up.
At Flowing Code we are not against it. We think it's a good thing. Just like Excel, it's the fastest way for the business to say what it needs, and often to solve it on its own.
They Are Born, They Get Used, They Multiply
The cycle is a familiar one. Apps are born to solve something specific, they get used, they work, and they multiply: one for purchasing, another to track complaints, another to approve expenses.
Some of them can stay that way forever, and that's fine. A tool that three people use to organize their work doesn't need anything more.
Others grow. They pick up users from other areas, start storing sensitive data, connect to other systems, or end up being used by external customers. At that point, maintaining them and getting them on track becomes IT's job. It's what used to happen with critical spreadsheets, and it's what IT departments at many large companies are dealing with today: a growing inventory of applications nobody planned, that work, that the business needs, and that someone has to keep running.
Signs That an App Needs to Level Up
Not every app needs to make the jump. But there are fairly clear signs that one is asking for it:
- Security. It handles personal, financial or customer data, and nobody has reviewed how it authenticates, who can see what, or how that data is protected.
- Performance. It ran fine with a handful of users; with more data or more people, it starts to slow down.
- Scalability. It was designed for one area, and now other areas, or other companies, want to use it.
- Auditing. Someone asks who changed a record, when and why, and there is no way to answer.
- Nobody knows how it works. The AI wrote the code, it works, and nobody on the team could explain what each part does.
- It depends on one person. If whoever built it goes on vacation or changes roles, the app is orphaned.
If an app in your organization shows two or three of these signs, it's no longer a personal tool: it's a system, and it needs to be treated like one.
A Real Case
This happened recently with one of our clients. They had an application built with vibe coding that had worked very well, so well that it kept growing and, by all indications, will end up as a product they offer to their own customers.
As it grew, they realized it wasn't scalable and didn't have the performance it would need for what was coming, so they called us to run an analysis. We did, and today we are working with them to evolve it, applying what we know about security, performance and scalability.
The important thing about this case is that there is nothing unusual about it. An app born in the business growing beyond what anyone planned is normal; it's almost proof that it was a good idea. What matters is solving it in time, before the customers are the ones who find the problem.
Two Paths for the Next Stage
Clean It Up
When an app has become serious, important and complex, at Flowing Code we take it, clean it up and turn it into an internal or external product with everything enterprise development needs: an architecture that can be understood and maintained, reviewed security, measured performance, tests, auditing, orderly deployments and a team that knows it.
This is not about throwing away what the business built. The existing app is the best specification you could ask for: it shows what is needed, how it's used and what works. Just like the spreadsheets, it's the starting point.
Give It a Track From the Start
The second path is for apps that are still being built, or that are worth steering before they grow. Almost every business application needs the same things: users and permissions, auditing, email, reports, configuration. If every vibe-coded app solves that in its own way, IT ends up maintaining ten different logins and ten ways of auditing.
AppJars provides that track. The common parts come as living components, maintained and updated outside each app, and the AI focuses only on what is specific to each application. It is, for real, the model the tweet was asking for: someone else maintains that part of the code. We explain it in detail in AI made building apps cheap. Owning them still isn't.
Let the Business Build
Vibe coding is here to stay, just like Excel. Business teams will keep building their own tools, and it's good that they do: it's one of the best ways companies have today to improve productivity.
What helps is being clear about what happens next. Most of those apps will be fine as they are. Some will grow, and those need a path.
If there is an app in your organization that started as a quick fix and is now asking for more, let's talk. We can help you take it to the next level.
Join the conversation!