Die kurze Antwort
Ja, eine vibe-codierte Anwendung kann übernommen werden.
Code aus Lovable, Bolt, v0, Cursor oder Claude Code ist nicht automatisch unbrauchbar. Entscheidend ist nicht «Wer hat den Code geschrieben?», sondern «Lässt sich dieses Produkt erklären, testen, absichern und betreiben, ohne von einem zufällig gelungenen Prompt abzuhängen?»
Ihr Prototyp funktioniert. Die Nutzenden verstehen das Versprechen. Vielleicht gibt es bereits Registrierungen, Daten oder Zahlungen. Dann werden Änderungen riskanter: Eine Korrektur beeinträchtigt einen anderen Bildschirm, die Zugriffsregeln der Datenbank sind schwer zu erklären, und niemand weiss, ob die Anwendung hundert Nutzende tragen kann – geschweige denn zehntausend.
Dann wird eine technische Übernahme meist sinnvoll. Es geht weder darum, die mit KI geleistete Arbeit abzuwerten, noch alles reflexartig neu zu schreiben. Es geht darum, festzustellen, was zuverlässig ist, was verstärkt werden muss und was für Ihr Unternehmen tatsächlich ein Risiko darstellt.
Das Hauptrisiko besteht nicht darin, dass KI einen Teil des Codes geschrieben hat. Es besteht darin, dass noch niemand die Verantwortung für seine technische Kohärenz trägt.
Übernahmedossier · 01
Sechs Prüfungen vor dem Produktivbetrieb
Eine überzeugende Demo zeigt, dass die Idee funktionieren kann. Diese sechs Punkte zeigen, ob das Produkt dauerhaft funktionieren kann.
- 01Prüfen
Code unter Kontrolle
Zugängliches Git-Repository, nutzbarer Verlauf, bekannte Abhängigkeiten und ein reproduzierbarer Einrichtungsprozess.
- 02Kritisch
Geschützte Daten
Serverseitig geprüfte Zugriffsregeln, keine Secrets im Browser, getestete Backups und ein klarer Ablageort für sensible Daten.
- 03Kritisch
Beherrschte Identitäten
Registrierung, Kontowiederherstellung, Rollen, Berechtigungen und Datenlöschung folgen expliziten Regeln.
- 04Prüfen
Testbare Nutzerwege
Wertschaffende Abläufe – Zahlung, Buchung, Teilen, Synchronisierung – verfügen über reproduzierbare Prüfungen.
- 05Kritisch
Geplanter Betrieb
Staging, Deployment, Monitoring, Warnungen, Wiederherstellung und Verantwortung bei Vorfällen sind festgelegt.
- 06Prüfen
Konforme Distribution
Datenschutz, Einwilligung, Drittanbieter-SDKs, Berechtigungen und Anforderungen von Apple und Google sind vor der Einreichung behandelt.
Ein roter Punkt verlangt keine vollständige Neuentwicklung. Er zeigt lediglich, wo Unsicherheit durch Nachweise ersetzt werden muss.
Übernahmedossier · 02
Vier mögliche Ergebnisse – nur eines bedeutet einen Neustart
Das Audit untersucht Code, Daten und Risiken, um den nötigen Aufwand bis zum nächsten Meilenstein zu bestimmen.
Wann
Lesbare Architektur, begrenzte Risiken, stabile kritische Nutzerwege.
Entscheidung
Die verbleibenden Lücken schliessen, das Produkt dokumentieren und den Launch vorbereiten.
Wann
Nützliches Produkt, aber Tests, Sicherheit oder Betrieb sind noch unvollständig.
Entscheidung
Prioritäre Risiken beheben, ohne das Funktionierende zu stören.
Wann
Die Oberfläche trägt, aber Daten, Authentifizierung oder Backend sind fragil.
Entscheidung
Das validierte Nutzungserlebnis erhalten und nur das betroffene Fundament ersetzen.
Wann
Datenmodell, Geschäftsabläufe und Oberfläche widersprechen sich grundlegend.
Entscheidung
Die Erkenntnisse des Prototyps behalten, nicht zwingend seinen Code.
Übernahmedossier · 03
Eine App übernehmen, ohne das bereits Validierte zu beschädigen
Eine Übernahme soll Unsicherheit in einer bewussten Reihenfolge reduzieren. Visuelle Komponenten zuerst zu refaktorieren, ist selten der beste Einsatz des Budgets.
- 01
Eine Referenzversion einfrieren
Repository, Umgebungen und Daten sichern und die Nutzerwege dokumentieren, die heute funktionieren.
Ergebnis
Reproduzierbare Ausgangsbasis
- 02
Nach Risiko auditieren
Zuerst Datenzugriff, Secrets, Zahlungen, Authentifizierung und kritische Abhängigkeiten prüfen.
Ergebnis
Kritikalitätsmatrix
- 03
Entscheiden, was bleibt
Für jede Schicht eine explizite Entscheidung treffen: behalten, korrigieren, isolieren oder ersetzen. Die Begründung dokumentieren.
Ergebnis
Kostenschätzung für die Übernahme
- 04
Das Deployment testen
Gezielte Tests, Staging, Monitoring und ein geprobtes Deployment ersetzen «Bei mir funktioniert es».
Ergebnis
Launch-Go/No-Go
Sonderfall · Mobile
Ein Web-Deployment ist noch keine veröffentlichungsreife App
Eine für das Web erzeugte Oberfläche kann eine nützliche Produktbasis sein. Die Veröffentlichung im App Store und bei Google Play bringt jedoch Verantwortlichkeiten mit sich, die eine Vorschau nicht sichtbar macht.
- Natives Verhalten, Navigation, Tastatur, Gesten und Betrieb auf realen Geräten
- Berechtigungen, Benachrichtigungen, Deep Links, In-App-Käufe und Kontoverwaltung
- Datenschutzerklärungen, Datenerhebung und Verantwortung für Drittanbieter-SDKs
- Signierte Builds, Zertifikate, Store-Einträge, Screenshots, Review und Update-Strategie
Codeexport und Übergabe des Betriebs
Lovable und Bolt erlauben die Synchronisierung oder den Export von Code, während v0 mit einem Vercel-Projekt verbunden wird. Das ist ein sehr guter Ausgangspunkt für eine Übernahme. Es ersetzt jedoch weder die Produktprüfung noch Sicherheitsentscheidungen oder die Vorbereitung für die Stores.
Lovable → GitHub
Codesynchronisierung für Backup, Zusammenarbeit und lokale Entwicklung.
Bolt → GitHub
Git-Verlauf und Möglichkeit, die Arbeit ausserhalb von Bolt fortzusetzen.
v0 → Vercel
Ein zugeordnetes Vercel-Projekt für Deployment und Laufzeitressourcen.
Expo → Stores
iOS- und Android-Builds sowie Einreichungen mit den Voraussetzungen des jeweiligen Stores.
Apple und Google machen Entwickelnde für das Verhalten der App, Drittanbieter-SDKs und Datenschutzerklärungen verantwortlich. Der Codeexport ist deshalb erst der Beginn einer Übernahme.
Häufige Fragen
Muss eine mit Lovable oder Bolt erstellte Anwendung immer neu geschrieben werden?
Nein. Oberflächen, Nutzerwege und Teile der Logik lassen sich oft erhalten. Die Entscheidung sollte nach Prüfung von Code, Daten und Geschäftsrisiken Schicht für Schicht getroffen werden.
Ist eine vibe-codierte App sicher?
Eine Demo kann diese Frage nicht beantworten. Zugriffsregeln der Datenbank, Secrets, Rollen, Abhängigkeiten, hochgeladene Dateien und im Browser sichtbare Daten müssen geprüft werden.
Kann der Code eines Lovable-Projekts übernommen werden?
Ja. Lovable kann ein Projekt mit GitHub synchronisieren. Das Repository kann anschliessend mit einem klassischen Engineering-Workflow auditiert und weiterentwickelt werden.
Kann aus einer vibe-codierten Web-App eine mobile Anwendung werden?
Ja, aber nicht durch eine einfache Verpackung. Das Nutzungserlebnis muss für Mobile angepasst, eine Architektur wie Expo und React Native gewählt sowie Berechtigungen, Builds, Datenschutz und Store-Regeln behandelt werden.
Wie lange dauert ein Übernahmeaudit?
Das hängt vom Umfang und von der Qualität des Repositorys ab. Ein nützliches Audit deckt mindestens Architektur, Sicherheit, Daten, kritische Nutzerwege und Betrieb ab und liefert einen priorisierten Plan statt einer allgemeinen Liste von Anmerkungen.
Was sollte vor der Übergabe der App an ein Team zuerst geschehen?
Eine Referenzversion erstellen: ein gesichertes Git-Repository, dokumentierte Zugänge, ein Inventar der Umgebungsvariablen, eine Datenkopie und eine Liste der heute funktionierenden Nutzerwege. Diese Ausgangsbasis schützt, was der Prototyp bereits erreicht hat.
Ihr nächster Meilenstein
Ein Application Audit anfragen
Appik Studio auditiert und übernimmt Web- und mobile Anwendungen aus Lausanne. Sie erhalten eine klare Einschätzung der Risiken, der wiederverwendbaren Elemente und des realistischen Wegs zum Launch.
Übernahmeanalyse anfragen
Swiss Made Software
