There is a seductive argument making the rounds now that we can use AI to “just” replace “old” enterprise apps with their newer versions. Why keep paying thousands of dollars for some ancient enterprise application when you could vibe-code the handful of features you actually use? Why keep that ugly 15-year-old internal application alive when one developer could rebuild it over a weekend? Look at how much simpler the replacement is. Look how quickly we built it and how little it cost.
But you’re comparing the wrong things. You built an app. You haven’t replaced an enterprise application. The difference is everything the organization needs before it can depend on what you built.
It was never about the code
When you use an application yourself, the application is mostly what you see. You need something, so you build it and deploy it to the cloud. If it breaks, you fix it. If you stop caring about it, you stop using it. But an important enterprise application doesn’t have that freedom because other people plan their work around it.
The more important an application is to the organization, the less its code represents the whole thing. An enterprise application gives the organization something it can depend on, and dependence comes with a long list of requirements. Is the application secure? Does it meet regulatory requirements? Who has access to its data, and where is that data stored? How is it backed up? What happens when the application goes down, and how quickly can it be restored? Who gets called at 3 a.m.? Who supports users and maintains the application? What happens when that person leaves? Who keeps its dependencies up to date and ensures it will still work five years from now?
When an organization buys an important application from a vendor, it buys features and assurance. The application needs to do what the business needs, of course. But surrounding those functional requirements is a much larger collection of non-functional requirements, processes, people, agreements and guarantees that make it possible for the organization to depend on the application. And you can’t vibe-code those.
You build it you own it
There’s an obvious counterargument: a large enterprise already has security teams, infrastructure, operations, support, compliance and all the other machinery needed to run applications. If the organization can build the replacement cheaply, why not run it on top of what it already has? Because just because you can, doesn’t mean you should.
Say, you’re an insurance company. Your goal isn’t to become an HR software company. If you’re a retailer, your competitive advantage isn’t maintaining your own expense management system. Your IT exists to support the business, and every hour spent maintaining an internal replacement for a commodity application is an hour that can’t be spent on technology that matters more to the business.
That’s exactly what a weekend prototype doesn’t show. Vibe coding can dramatically reduce the effort required to create an application. Yet ownership extends far beyond creating it. Once you replace the vendor, someone needs to own the replacement, not just today while building it is exciting, but next year and five years from now. Someone needs to deal with incidents, vulnerabilities, changing requirements, dependencies, support, documentation, migrations and eventually the replacement of the replacement. AI makes the code cheaper while leaving that responsibility with the organization.
A replacement needs a business reason
There’s an even earlier question: why are we doing this? After all, enterprise organizations have more work than people to do it. Security teams are busy. IT and support are busy. The people who need to be trained are busy doing their actual jobs. And replacing a working app competes for all of their time.
So imagine showing up with your shiny vibe-coded replacement. It works. It’s cheaper and perhaps even nicer than the application everyone uses today. Great. Why should everyone drop what they’re doing to help you roll it out? Someone needs to review and approve it. Someone needs to migrate the existing data and prepare the rollout. Users might need training. The support organization needs to know how to support it, and existing integrations might need changing. All of those people could be doing something else. What does the organization gain by having them work on this instead?
And this question applies just as much to that terrible 15-year-old internal application. Just because it’s old and looks dated, doesn’t create a business reason to replace it. But say, that the app is running on infrastructure that needs to be retired. Or it’s got security issues, or can no longer support what the business needs, or if maintenance costs that have become prohibitive: any of those things might justify updating the app. But being able to build a nicer version establishes none of those needs.
Vibe coding can be an excellent implementation technique once you’ve established the need to modernize. The technique gives you a way to build the replacement, but it doesn’t supply the reason to start. And there’s an option that’s strangely easy to overlook when we’re excited about what we can build: do nothing. Not doing something is always an option.
Compare the full picture
This is why comparisons such as “we pay $100,000 a year for this application and I reproduced it for $5,000” aren’t particularly useful. The $5,000 figure leaves out hidden costs. More importantly, reproducing the application’s functionality doesn’t reproduce what the organization depends on.
To seriously propose replacing an enterprise application, you need to show the full picture. The replacement needs to meet the organization’s functional and non-functional requirements. Switching needs to offer a clear benefit. You need to understand the total cost of ownership rather than just the cost of producing the code, and you need to understand the return on that investment.
You also need to account for opportunity cost. What aren’t we doing because we’re doing this? The answer may still favor the replacement because plenty of enterprise applications should be retired. But answering that question moves the discussion from admiring a prototype to deciding whether the organization should adopt and own it.
To vibe coding or not?
None of this means enterprises shouldn’t vibe-code applications. Quite the opposite. Personal and team productivity are particularly promising places to benefit from how cheap software has become. Build the little tool that saves you twenty minutes every morning. Build something that removes an annoying manual step for your team. Build the interface that makes an awkward internal process easier. In all these cases, the blast radius is small, only few people depend on it, and the business doesn’t grind to a halt if it disappears tomorrow. You can tolerate things there that you can’t tolerate in a business-critical system.
And it might just happen that one of those little applications will become successful. First one person uses it, then a team. Another team discovers it, and before long hundreds of people depend on it. At some point, something interesting happens: the application hasn’t necessarily changed, but the dependency has. As a result, ownership needs to be formalized, and the application starts attracting organizational scrutiny. Security, support, continuity and all those other concerns that seemed unnecessary for the little team tool start to matter all of a sudden. Success turns the vibe-coded app into an enterprise application, bringing with it everything around the code.
AI has changed the economics of producing software. Things that weren’t worth automating before can now be worth automating. Individuals and teams can create software tailored to problems too small to justify a traditional development project, and organizations should take advantage of that.
But cheaper code doesn’t make organizational change cheaper. Reproducing the visible functionality of an enterprise application still leaves you to recreate the conditions that made the organization depend on it. The screens show only part of the product, and the code accounts for only part of the cost. So the next time someone looks at an expensive enterprise application and says, “We could just vibe-code that,” picture the iceberg (I know, but bear with me). They’ve built the part above the water. What makes an app an enterprise application is everything underneath.