Vibe Coding for Enterprise Apps: 6 Steps from Prototype to Production
Vibe coding for enterprise apps: the 6 steps that turn an AI-built prototype into a production app. Deployment, security, users, versioning, backups, licensing.
By Johannes Mohren ·
More and more companies are experimenting with vibe coding: for internal tools, dashboards and small process apps. What makes it different is who does the building. It's often not developers, but the people who know the process best: controllers, production managers, back-office staff. That's the real strength of vibe coding. The best idea for a solution usually comes from the person who has the problem every day, not from the IT department that only hears it described.
A few prompts later, there's a first version: an HTML page in your downloads folder, or a tool running at http://localhost:8080/ in your own browser. That's already a real result. It's also the starting point for the actual question: what's still missing before this prototype becomes an application that runs productively in the company, that several colleagues can use safely, and that still works reliably a year from now?
The answer isn't a long to-do list. It's six clear steps that, in practice, become relevant in this order. And for most of them, your company already has a foundation that other software has used for years. You just need to know it's there and reuse it.
Step 1: Deployment moves the app from your laptop into the company
When you build an app with an AI such as Claude or ChatGPT, it first runs only on your machine: as an HTML file in the chat, or behind a localhost link in your browser when you use development tools such as Cursor or Claude Code. It already feels like a finished app. Technically, though, only your laptop can reach it.
As soon as a colleague tries to open the same link, their computer finds nothing to answer it. For others to get access, the app has to run somewhere they can reach too. That's called deployment.
User opens the app in the browser
The user only sees the UI. The backend and database only come in with deployment.
Where should a vibe-coded app run?
The good news: you usually don't need to look for a new provider. If your company works with Microsoft 365, it usually already has a cloud environment built for exactly this: Microsoft Azure. So the easiest first step isn't a research project. It's a short question to IT: "Where can we host a small internal app?"
Technically, simple applications often only need static hosting: the files sit ready and are delivered when someone opens the page. But as soon as the app processes input, runs calculations or talks to a database, it needs a server that actively runs code instead of just serving files.
Why an enterprise app needs a database
A quickly built prototype often saves changes only in the browser. You enter data, everything looks fine, you reload the page, and the data is gone. A database gives the app the memory it's been missing.
Two kinds work together here:
- Relational databases suit structured, searchable data. The classic example is a ticket system with the creator, creation date, problem description and owner.
- Object storage suits files such as images, Excel sheets or PDFs.
In practice, you almost always need both. The table stores the ticket data, including a path to the attached file, while the file itself sits in object storage.
Step 2: Data security means opening only as much as necessary
Once an app is reachable on the network or publicly, the question comes up: who can actually access it, and what could go wrong? The most important rule of thumb in IT security is simple: the smaller the attack surface, the fewer security gaps are possible.
You already know the principle from your company network. Your file server isn't directly reachable from the internet, only through authorized access. In the same way, the database behind a new app should never be directly reachable from the internet, whether it runs in the cloud or in your own data center. Instead, an API sits in between: a dedicated, lean service that defines exactly which requests are allowed and which aren't. The database itself stays invisible from the outside.
Step 3: User management decides who sees what
Once several people use an app, "everyone can do everything" no longer works. Two terms come into play here. They're often confused, but they answer different questions:
- Authentication answers the question: Who are you? This covers the login screen and protecting individual pages (route protection), so people who aren't logged in can't get in at all.
- Authorization answers the question: Now that we know who you are, what are you allowed to do? This is usually solved with role-based access control (RBAC). An admin can manage users, for example, while a regular employee can only see their own tickets.
Sign-in via Entra ID / SSO
Employee
Admin
See own tickets
See all tickets
Manage users
Here too, you rarely start from zero. If your company already works with Microsoft 365, a new app can connect directly to Entra ID (formerly Azure AD). Employees then sign in with their existing company account: no new password, no user management built from scratch. What's left is the content question: which user groups will your app have, and what does each of them really need to see and do?
Step 4: Versioning and rollback let you ship changes safely
An enterprise app never stands still. New requirements keep coming in. The question is what happens when a change introduces a bug that only shows up after it's rolled out.
Versioning means every state of your app is saved in a traceable way. The standard for this is Git: a tool that records every change to the code, so you can always see who changed what and when, and jump back. This history is usually stored with a provider such as GitHub (owned by Microsoft), GitLab or, if you already work in the Microsoft ecosystem, directly in Azure DevOps.
Rollback builds on this: the ability, when something goes wrong, to jump back to the last working version with one click, instead of repairing things live while every user watches.
Like a document version history: v3 is live, and v2 and v1 can be restored with one click.
You already know this on a small scale from Word or SharePoint. When a colleague accidentally overwrites a document, you simply restore the previous version from the version history. Your app needs exactly the same principle, just for the entire state of code and data instead of a single document.
Step 5: Backups prepare you for the worst case
Versioning protects your code, but it says nothing about your data. A database backup is your insurance against data being lost for good through a bug, an attack or an accidental deletion.
Your ERP or inventory system wouldn't run without an automatic daily backup. A new app needs the same protection from day one, not only after something has gone wrong.
One term you'll hear often is point-in-time recovery: the ability to restore the database not just to the last nightly backup, but to any moment you choose, for example "10:42:17, just before the faulty change went in". For an application that really runs productively in the company, that's the difference between a minor annoyance and real data loss.
Step 6: Licensing is the underestimated trap in AI-generated code
One point that's easy to overlook in vibe coding: when AI models build an app, they often pull in existing open-source libraries. These come under different licenses, and not every license allows every use, especially in a commercial company setting.
The rough distinction:
- Permissive licenses (such as MIT or Apache) are usually unproblematic and allow almost unrestricted use, including in closed, commercial software.
- Copyleft licenses (such as GPL) can require you to publish your own code too, if it includes the library. For an internal enterprise app with proprietary business logic, that can be a real problem.
When software is bought from an outside vendor, the vendor usually handles this check, mostly with automated tests, while your legal or compliance team requests the relevant information during purchasing. The same logic applies to AI-generated code. The difference is that nobody checks it automatically when you yourself are the app's "vendor".
Building software with AI is easy.
Enterprise applications aren’t.
Running enterprise apps
Deployment
Database
Data Security
Role-based access
User Management
Versioning & rollback
Audit logs
“Can you just add one more field?”
The checklist: from vibe-coded prototype to enterprise app
These six points are what separate a prototype from an enterprise app. Not the idea, and not the interface:
- Deployment: Where does the app run, and where is the data stored (relational and/or object storage)?
- Data security: Is the attack surface minimal, and is the database never directly public?
- User management: Who are you (authentication), and what are you allowed to do (authorization)?
- Versioning and rollback: Can I go back safely if something breaks?
- Backups: Can the data be restored even in a worst case?
- Licensing: Are we actually allowed to use the building blocks this way?
The good news: for most of these points, your company already has a solution that other software has used for years: Entra ID, your cloud environment, the backup concept of your ERP system. You don't need to reinvent any of it. You just need to know that it applies to your new app as well.
Now that you've heard these terms once, you can judge for yourself where your next prototype stands on this path, and research further in a targeted way. The IT perspective on Arctory shows how these six points can be addressed in practice.
Back to the blog
