Vibe Coding Guide für Enterprise Apps: Vom Prototyp zur produktionsreifen Anwendung
Deployment, Datenbank, Security, User Management, Versionierung, Backups und Lizenzen: die 6 Schritte, um eine vibe-gecodete App enterprise-ready zu machen.
By Johannes Mohren ·
Immer mehr Unternehmen fangen an, mit Vibe Coding zu experimentieren – für interne Tools, Dashboards, kleine Prozess-Apps. Das Besondere dabei: Es sind oft nicht die Entwickler, die bauen, sondern die Menschen, die den Prozess selbst am besten kennen – Controller, Produktionsleiter, Sachbearbeiter. Genau das ist die Stärke von Vibe Coding: Die beste Idee für eine Lösung kommt meistens von der Person, die das Problem täglich hat, nicht von der IT-Abteilung, die es nur beschrieben bekommt.
Nach ein paar Prompts steht dann eine erste Version: eine HTML-Seite im Download-Ordner, oder ein Tool, das unter http://localhost:8080/ im eigenen Browser läuft. Das ist bereits ein echtes Ergebnis – und der Ausgangspunkt für die eigentliche Frage: Was fehlt noch, damit aus diesem Prototyp eine Anwendung wird, die im Unternehmen produktiv läuft, für mehrere Kollegen sicher nutzbar ist und auch in einem Jahr noch verlässlich funktioniert?
Die Antwort ist keine lange To-Do-Liste, sondern sechs klare Schritte, die in der Praxis in dieser Reihenfolge relevant werden. Und für die meisten davon gibt es in deinem Unternehmen schon eine Grundlage, die für andere Software längst im Einsatz ist – du musst sie nur kennen und wiederverwenden.
Schritt 1: Deployment – vom eigenen Rechner ins Unternehmen
Wenn du mit einer KI wie Claude oder ChatGPT eine App baust, läuft sie zunächst nur bei dir: als HTML-Datei im Chat, oder in Entwicklungsumgebungen wie Cursor oder Claude Code unter einem localhost-Link im eigenen Browser. Das fühlt sich schon wie eine fertige App an – ist aber technisch gesehen nur auf deinem Laptop erreichbar.
Sobald ein Kollege denselben Link öffnen will, findet sein Rechner nichts, was ihn bedient. Damit andere zugreifen können, muss die App an einem Ort laufen, den auch sie erreichen – das nennt man Deployment.
Wo soll die App laufen?
Die gute Nachricht: Meistens musst du dafür keinen neuen Anbieter suchen. Wenn euer Unternehmen mit Microsoft 365 arbeitet, gibt es mit Microsoft Azure in der Regel schon eine Cloud-Umgebung, die genau dafür gedacht ist. Der einfachste erste Schritt ist deshalb kein Research-Projekt, sondern eine kurze Frage an die IT: „Wo können wir eine kleine interne App hosten?"
Technisch reicht für einfache Anwendungen oft Static Hosting – die Dateien liegen bereit und werden bei Aufruf ausgeliefert. Sobald die App aber Eingaben verarbeitet, Berechnungen durchführt oder mit einer Datenbank spricht, braucht sie einen Server, der aktiv Code ausführt statt nur Dateien bereitzustellen.
Warum die App ein Gedächtnis braucht
Ein schnell erstellter Prototyp speichert Änderungen oft nur im Browser: Du trägst Daten ein, alles sieht gut aus, du lädst die Seite neu – und die Daten sind weg. Eine Datenbank gibt der App das Gedächtnis, das ihr bisher fehlt.
Dabei ergänzen sich zwei Arten:
- Relationale Datenbanken eignen sich für strukturierte, durchsuchbare Daten. Das klassische Beispiel: ein Ticketsystem mit Ersteller, Erstellungsdatum, Problembeschreibung und Zuständigkeit.
- Object Storage eignet sich für Dateien wie Bilder, Excel-Sheets oder PDFs.
In der Praxis werden fast immer beide gebraucht: Die Tabelle speichert die Ticketdaten inklusive eines Pfads zur angehängten Datei, während die Datei selbst im Object Storage liegt.
Schritt 2: Data Security – nur so viel öffnen wie nötig
Sobald eine App im Netzwerk oder öffentlich erreichbar ist, kommt die Frage: Wer kann eigentlich darauf zugreifen, und was könnte schiefgehen? Die wichtigste Faustregel der IT-Sicherheit lautet dabei: Je kleiner die Angriffsfläche, desto weniger Sicherheitslücken sind möglich.
Das Prinzip kennst du bereits aus eurem Firmennetz: Genauso wie euer Fileserver nicht direkt aus dem Internet ansprechbar ist, sondern nur für berechtigte Zugriffe, sollte auch die Datenbank einer neuen App niemals direkt aus dem Internet erreichbar sein – egal ob sie in der Cloud oder im eigenen Rechenzentrum läuft. Stattdessen läuft dazwischen eine API – ein dedizierter, schlanker Dienst, der genau festlegt, welche Anfragen erlaubt sind und welche nicht. Die Datenbank selbst bleibt nach außen unsichtbar.
Schritt 3: User Management – wer sieht was
Sobald mehrere Personen eine App nutzen, reicht es nicht mehr, dass „jeder alles kann". Hier kommen zwei Begriffe ins Spiel, die oft verwechselt werden, aber unterschiedliche Fragen beantworten:
- Authentifizierung beantwortet die Frage: Wer bist du? Dazu gehört der Login-Bildschirm und der Schutz einzelner Seiten (Route Protection), sodass nicht eingeloggte Personen gar nicht erst hineinkommen.
- Autorisierung beantwortet die Frage: Was darfst du, jetzt wo wir wissen, wer du bist? Das wird meist über rollenbasierte Zugriffskontrolle (RBAC) gelöst: Ein Admin darf zum Beispiel Nutzer verwalten, ein normaler Mitarbeiter nur seine eigenen Tickets sehen.
Auch hier musst du selten von null anfangen: Wenn ihr im Unternehmen schon mit Microsoft 365 arbeitet, lässt sich eine neue App direkt an Entra ID (ehemals Azure AD) anbinden. Mitarbeiter loggen sich dann mit ihrem bestehenden Firmen-Account ein – kein neues Passwort, keine Nutzerverwaltung von Grund auf. Was bleibt, ist die inhaltliche Frage: Welche Nutzergruppen wird es in deiner App überhaupt geben, und was muss jede davon wirklich sehen und tun können?
Schritt 4: Versioning & Rollback – Änderungen sicher ausrollen
Eine Enterprise App steht nie still: Es kommen laufend neue Anforderungen dazu. Die Frage ist, was passiert, wenn eine Änderung einen Fehler einführt, der erst nach dem Ausrollen auffällt.
Versionierung bedeutet, dass jeder Stand deiner App nachvollziehbar gespeichert wird. Der Standard dafür heißt Git: ein Werkzeug, das jede Änderung am Code protokolliert und dabei speichert, sodass man jederzeit nachvollziehen und zurückspringen kann, wer was wann geändert hat. Gespeichert wird dieser Verlauf meist bei einem Anbieter wie GitHub (gehört zu Microsoft), GitLab oder – wenn ihr ohnehin im Microsoft-Umfeld arbeitet – direkt in Azure DevOps.
Darauf baut die Fähigkeit zum Rollback auf: die Möglichkeit, im Ernstfall mit einem Klick zur letzten funktionierenden Version zurückzuspringen, statt live im Betrieb zu reparieren, während alle Nutzer zusehen.
Im Kleinen kennst du das bereits aus Word oder SharePoint: Wenn eine Kollegin ein Dokument versehentlich überschreibt, holt man sich über die Versionshistorie einfach die vorherige Fassung zurück. Genau dieses Prinzip braucht auch deine App – nur für den gesamten Code- und Datenstand statt für ein einzelnes Dokument.
Schritt 5: Backups – für den Ernstfall vorsorgen
Versionierung schützt deinen Code, sagt aber nichts über deine Daten aus. Ein Backup der Datenbank ist die Absicherung dagegen, dass Daten durch einen Fehler, einen Angriff oder ein versehentliches Löschen unwiederbringlich verloren gehen.
Genauso wie euer ERP- oder Warenwirtschaftssystem nicht ohne automatisches, tägliches Backup laufen würde, braucht auch eine neue App diese Absicherung von Anfang an – nicht erst, nachdem etwas schiefgegangen ist.
Ein Begriff, den du dabei öfter hören wirst, ist Point in Time Recovery: die Fähigkeit, die Datenbank nicht nur auf das letzte nächtliche Backup zurückzusetzen, sondern auf einen beliebigen Zeitpunkt – zum Beispiel „10:42:17 Uhr, kurz bevor die fehlerhafte Änderung eingespielt wurde". Für eine Anwendung, die wirklich im Unternehmen produktiv läuft, ist das der Unterschied zwischen einem kleinen Ärgernis und einem echten Datenverlust.
Schritt 6: Licensing – die unterschätzte Falle bei KI-Code
Ein Punkt, der bei Vibe Coding leicht übersehen wird: KI-Modelle greifen beim Bauen einer App häufig auf bestehende Open-Source-Bibliotheken zurück. Diese stehen unter unterschiedlichen Lizenzen, und nicht jede Lizenz erlaubt jede Nutzung – gerade nicht in einem kommerziellen Unternehmenskontext.
Die grobe Unterscheidung:
- Permissive Lizenzen (zum Beispiel MIT oder Apache) sind meist unkritisch und erlauben nahezu freie Nutzung, auch in geschlossener, kommerzieller Software.
- Copyleft-Lizenzen (zum Beispiel GPL) können hingegen verlangen, dass du deinen eigenen Code, sofern er die Bibliothek einbindet, ebenfalls offenlegst. Für eine interne Enterprise App mit proprietärer Geschäftslogik kann das ein echtes Problem sein.
Wird Software klassisch extern eingekauft, übernimmt diese Prüfung in der Regel der Anbieter selbst, meist mit automatisierten Tests, während eure Rechtsabteilung oder Compliance die entsprechenden Informationen beim Einkauf abfragt. Bei KI-generiertem Code gilt dieselbe Logik – nur prüft sie hier niemand automatisch, wenn du selbst der „Anbieter" der App bist.
Fazit: Die Checkliste vom Prototyp zur Enterprise App
Genau diese sechs Punkte unterscheiden einen Prototyp von einer Enterprise App – nicht die Idee oder die Oberfläche:
- Deployment: Wo läuft die App, und wo werden die Daten gespeichert (relational und/oder object)?
- Data Security: Ist die Angriffsfläche minimal, und läuft die Datenbank nie direkt öffentlich?
- User Management: Wer bist du (Authentifizierung), und was darfst du (Autorisierung)?
- Versioning & Rollback: Kann ich im Fehlerfall sicher zurück?
- Backups: Sind die Daten auch bei einem Ernstfall wiederherstellbar?
- Licensing: Dürfen die verwendeten Bausteine überhaupt so genutzt werden?
Die gute Nachricht dabei: Für die meisten dieser Punkte gibt es in deinem Unternehmen bereits eine Lösung, die für andere Software längst im Einsatz ist – Entra ID, eure Cloud-Umgebung, das Backup-Konzept eures ERP-Systems. Du musst nichts davon neu erfinden, nur wissen, dass es für deine neue App genauso gilt.
Wenn du diese Begriffe jetzt einmal gehört hast, kannst du selbst einschätzen, wo dein nächster Prototyp auf diesem Weg steht – und gezielt weiter recherchieren. Wie diese sechs Punkte in der Praxis konkret adressiert werden können, zeigt die IT-Perspektive auf Arctory.
Back to the blog