Just because an app is used in an enterprise doesn’t make it an enterprise app. Yet as AI coding agents make software easier to build, we’re seeing people build apps over a weekend and conclude that enterprises should be able to do the same: replace expensive software, modernize old systems and get rid of costly contracts.
But building an app at work isn’t the same as building software the business relies on. An app becomes an enterprise app when the business depends on it, not simply because it happens to be used there.
Dependency draws the boundary
Imagine I build a reporting app for myself at work. It connects to company data, helps me do my job and I use it every day. If it goes down tomorrow, I’m inconvenienced: maybe I can’t get my report for a while, but I can fix it, work around it or wait until later. Since the rest of the organization doesn’t care, it is an app used in an enterprise.
Now imagine a technically similar reporting app that Finance uses to prepare the company’s annual report. If that app goes down at the wrong moment, people can’t do their jobs, deadlines might be missed and the business is affected. That dependency makes it an enterprise app.
What makes it an enterprise app isn’t necessarily its technology, who built it, how they built it or whether a vendor provides it as SaaS. It is the business’s dependency on it.
Why define the category by dependency?
There is another reasonable way to use the term. An enterprise app can mean software designed for large organizations: software that supports many users, integrates with corporate systems or is sold through an enterprise contract. Under that definition, an application can be an enterprise app even when no important business process depends on it. A small internal tool might not count even when losing it would stop people from working. That definition is useful when describing a market or a product’s design, but less useful when deciding what an organization must do to keep operating.
Here, “enterprise app” is a governance category. The label identifies the condition that creates the obligations associated with enterprise software. Large scale, a particular architecture and a procurement model don’t by themselves explain why an app needs monitoring, support, continuity planning or formal ownership. Business dependency does.
This doesn’t mean every dependent app needs the same controls. An application supporting a small internal process doesn’t warrant the same scrutiny as one required to close the books or run a factory. Dependency can make an app an enterprise app while the consequences of failure determine how much engineering, operational support and governance it requires.
The code can stay the same while the risk changes
An app can also move from one category to the other. Someone builds a small tool for themselves, then their team starts using it. Another team picks it up, and before long dozens or hundreds of people rely on it. Even if the code barely changes, losing the app now affects far more people.
That change creates questions that didn’t matter when the app had one user. How available does it need to be? Who monitors it? Who supports it when something breaks? How is it secured? Who maintains it when its original developer leaves? How quickly must it recover after an outage? What happens when one of its dependencies disappears?
A tool can fly under the radar for quite some time, and its first serious outage is often the moment everyone discovers how important it has become. Getting ahead of that discovery is exactly what enterprise governance is for.
The resulting requirements around security, availability, monitoring, support, maintenance and business continuity can look like bureaucracy. They’re not, at least not for the sake of it. They exist because someone needs the application to work tomorrow, next month, when its developer is on vacation, when a dependency fails and when the business changes.
Calling every work app an enterprise app also diminishes the work involved in building and running software the business relies on. It makes everything beyond producing functioning code invisible: engineering, operations, security, compliance, support, governance, maintenance and everyone responsible for ensuring the business can continue to depend on it.
Vibe coding in an enterprise is not the same as vibe coding enterprise apps
AI coding agents can make it dramatically easier for employees to build useful software for themselves and their teams. That gives enterprises plenty of room for small apps that solve local problems without carrying the weight of enterprise software. Not everything needs enterprise-grade processes, guarantees and governance from day one.
Still, where an app is used doesn’t tell you how much the organization depends on it, and producing a working app doesn’t establish the ownership needed to keep a business-critical application working. As more people and processes rely on an app, ownership, support, security and continuity must grow with the consequences of losing it. The transition happens when the business can no longer do without the app, whether or not its code has changed.
So the next time you see a discussion about replacing enterprise apps, ask yourself: are these actual enterprise apps or apps in an enterprise.