Der Prototyp in Lovable funktioniert, Sie klicken sich durch und alles läuft wie geschmiert. Doch bevor eine Lovable-App in die Produktion geht, muss das Team Code und Datenbank übernehmen, die Sicherheit prüfen und entscheiden: Entwickeln wir den Prototyp weiter oder bauen wir neu?
Ein funktionierender Prototyp testet eine Idee. Echte Kunden spielen in Sachen Zuverlässigkeit in einer ganz anderen Liga. Vibe Coding im Unternehmen, also das Erstellen von Apps per Anweisungen in natürlicher Sprache in Lovable, Bolt und ähnlichen Tools, verkürzt den Weg zur ersten Version deutlich. Und das ist gut so. Dieser Text richtet sich an Geschäftsführer und Product Manager, die einen solchen Prototyp haben und ein Team für die Weiterentwicklung suchen.
Inhaltsverzeichnis
Wo liegen Code und Datenbank des Prototyps, und wer hat Zugriff darauf?
Der Code des Projekts liegt in Lovable. Sie können ihn aber mit einem GitHub-Repository mit bidirektionaler Synchronisierung verbinden oder ihn herunterladen, wenn Sie einen kostenpflichtigen Plan haben. Laut der Dokumentation zur GitHub-Integration von Lovable ist das beim Verbinden erstellte Repository standardmäßig privat. Prüfen Sie trotzdem, ob es in der Organisation des Unternehmens liegt und nicht im privaten Konto der Person, die den Prototyp zusammengeklickt hat.
Vorsicht beim Trennen der Integration. Danach endet die Synchronisierung: Das Repository bleibt auf GitHub, aber alle weiteren Änderungen werden nur noch in Lovable gespeichert. So entstehen schnell zwei auseinanderlaufende Versionen des Codes. Legen Sie deshalb vor der Übergabe eine einzige verbindliche Quelle fest. Erfassen Sie außerdem alle Personen und Konten mit Zugriff auf Lovable, GitHub und die Datenbank. Überflüssige Berechtigungen? Entziehen.
Was enthält der Datenbankexport, und was muss manuell umziehen?
Unter dem Prototyp arbeitet PostgreSQL. Laut der Lovable-Dokumentation zum Datenbankexport umfasst der Export Struktur und Daten, einschließlich der Benutzerkonten. Klingt vollständig, ist es aber nicht. Eine laufende App stützt sich auf einige Dinge, die Sie im Export nicht finden. Separat übertragen werden müssen:
- im Storage gespeicherte Dateien, etwa Fotos und Dokumente, die Nutzer hochgeladen haben,
- der Code der Edge Functions, also der Funktionen, die serverseitig laufen,
- Secrets und API-Schlüssel für externe Dienste,
- die Konfiguration der Anmeldung und der Authentifizierungsanbieter.
Das Backend zu einem anderen Anbieter umzuziehen ist Arbeit für einen Entwickler, kein einzelner Klick. Planen Sie sie vom ersten Tag an in Zeitplan und Budget ein. Denn ohne diese Elemente startet die App nach der Migration schlicht nicht.
Sicherheitsprüfung einer KI-generierten App: Secrets, RLS und Serverlogik
Regel Nummer eins: Frontend-Code läuft im Browser und darf daher nicht über die Sicherheit entscheiden. Und jedes Secret, das dort landet, gilt als offengelegt. So formulieren es die Sicherheitsempfehlungen von Lovable, und genau damit sollte die Prüfung beginnen. Durchsuchen Sie den Frontend-Code nach Schlüsseln und Tokens, machen Sie diese ungültig und verlagern Sie sie auf den Server.
Der zweite Bereich ist RLS (Row Level Security), also Regeln, die festlegen, welche Datensätze ein Nutzer in der Datenbank sieht, dazu die Rollenberechtigungen. Die Kontrollfrage ist einfach: Kann ein angemeldeter Kunde fremde Daten lesen oder ändern? Wenn ja, haben Sie ein Problem. Auch eine Validierung auf Clientseite schützt nichts. Geschäftsregeln und Datenkontrolle gehören auf den Server. Wie die Reparatur von KI-generiertem Code in der Praxis aussieht, beschreiben wir ausführlich in einem eigenen Beitrag.
Checkliste vor der Übernahme des App-Codes
Bevor das Team den Code übernimmt, geht es einige Bereiche durch, um die sich im Prototyp meist niemand gekümmert hat:
- Eigentum an Repository und Datenbank: Organisation des Unternehmens, Liste der Konten mit Zugriff.
- Secrets und Schlüssel im Frontend-Code.
- RLS-Regeln und Rollenberechtigungen.
- Logik auf dem Server statt im Browser.
- Automatisierte Tests, die meist fehlen.
- Backups von Datenbank und Dateien sowie deren Wiederherstellung.
- Kosten der Dienste im Hintergrund: Datenbanken, Funktionen, externe APIs.
- Personenbezogene Daten: welche erhoben werden, wohin sie gehen und wer sie sieht.
Eine App, die Kundendaten verarbeitet, unterliegt den Datenschutzvorschriften. In der Europäischen Union ist das die DSGVO, und man sollte sich nichts vormachen: Ein Prototyp ist davon nicht ausgenommen. Die Dienste im Hintergrund sind wiederum ein fester Bestandteil der Wartung einer KI-App. Berechnen Sie gleich die laufenden Wartungskosten der App nach dem Livegang, bevor Sie die erste Rechnung überrascht.
Prototyp weiterentwickeln oder die App neu bauen?
Weiterentwickeln, wenn die Struktur von Code und Datenbank verständlich ist und die Sicherheitskorrekturen punktuell bleiben. Muss das Fundament angefasst werden, behandeln Sie den Prototyp besser als Spezifikation. Was spricht für die Weiterentwicklung? Ein stimmiges Datenmodell. Logik, die sich auf den Server verlagern lässt. Und ein Technologie-Stack, in dem sich das Team zu Hause fühlt.
Für einen Neubau sprechen Logik, die über das gesamte Frontend verstreut ist, fehlende Zugriffskontrolle oder geplante Funktionen, die die aktuelle Architektur nicht tragen kann. Aber selbst dann landet der Prototyp nicht im Papierkorb. Er zeigt Abläufe, Screens und Nutzerbedürfnisse, die sich bereits bewährt haben, und das ist viel wert. Auf dieser Grundlage kann eine erste Produktversion auf stabilem Fundament entstehen.
Wie übergeben Sie einen KI-App-Prototyp an ein Entwicklerteam?
Start: Zugriff auf das Firmen-Repository, Datenbankexport und eine Liste der Elemente außerhalb des Exports. Ziel: ein gemeinsames Code-Review. Bereiten Sie unterwegs eine kurze Beschreibung des App-Zwecks vor, eine Liste der Funktionen, die Kunden tatsächlich nutzen (nicht der geplanten), bekannte Fehler und eine Übersicht der Konten und externen Dienste.
Das Team, das das Projekt übernimmt, führt das Review durch, plant die Backend-Migration, schreibt Tests, richtet Backups ein und übernimmt die weitere Wartung. Sie suchen einen Dienstleister für jede dieser Phasen? Wir beschreiben, wie bei uns die Softwareentwicklung nach Maß abläuft.
Lovable-App in die Produktion bringen: Womit anfangen
Ein Prototyp, der per Anweisungen in natürlicher Sprache entstanden ist, ist ein wertvoller Beweis, dass die Idee Sinn ergibt. Stabilität unter der Last echter Nutzer garantiert er jedoch nicht. Erst die Prüfung anhand der Checkliste, dann die Entscheidung: Weiterentwicklung oder Umbau. Unterm Strich läuft alles auf drei Punkte hinaus. Wer eine Lovable-App in die Produktion bringen will, muss Code-Eigentum, Sicherheit und die künftige Architektur klären.
Häufige Fragen
Gehört mir der Code aus Lovable, und kann ich ihn mitnehmen?
Der Code lässt sich mit einem GitHub-Repository synchronisieren oder in kostenpflichtigen Plänen herunterladen. Achten Sie nur darauf, dass das Repo in der Organisation des Unternehmens liegt und nicht im privaten Konto des Erstellers. Dann bedeutet die Übergabe an ein Team im Grunde nur, Berechtigungen zu vergeben.
Reicht der Datenbankexport aus Lovable, um die App umzuziehen?
Nein. Der Export umfasst Struktur, Daten und Benutzerkonten, aber keine Dateien im Storage, keinen Code der Edge Functions, keine Secrets, keine Anmeldeeinstellungen und keine API-Schlüssel. Diese überträgt ein Entwickler separat.
Übernimmt man eine mit Bolt gebaute App genauso?
Im Großen und Ganzen ja, die Prüfkriterien sind dieselben: Code, Datenbank, Secrets, Berechtigungen und Tests. Die Details des Exports hängen vom jeweiligen Tool ab, werfen Sie also vor der Übergabe einen Blick in dessen Dokumentation.
