Vom Lovable- und Cursor-Prototyp in Produktion: Die Migrations-Checkliste

KI-unterstützte Builder wie Lovable, Cursor, Claude Code, Bolt, v0 und Replit können den Weg zu einem klickbaren Produkt verkürzen. Das ist echter Fortschritt, aber "die Demo läuft" beweist nicht, dass "echte Nutzer sich darauf verlassen können." Produktionsreife ist ein eigener Nachweisbereich, dessen Umfang von Architektur, Daten, Bedrohungen, Regulierung und möglichem Schaden abhängt. Das ist unsere Erstprüfung für den Weg eines Prototyps in Produktion.

Nichts davon ist ein Vorwurf an die Tools, und der Toolname entscheidet nicht über Produktionstauglichkeit. Lovable und Replit dokumentieren Produktions-Deployments; Lovable dokumentiert außerdem GitHub-Sync, Sicherheitsprüfungen und Backend-Secret-Speicher. Prüfe den genauen Plan und die Architektur. Die Checkliste erfasst Kontrollen, die unabhängig davon Nachweise brauchen, ob Code generiert oder von Menschen geschrieben wurde.

Prototyp mit einer KI-IDE gebaut?

Production-Readiness-Review buchen

Was heißt "Produktion" eigentlich?

Eine Demo kann belegen, dass Idee und Interaktion funktionieren. Produktionsreife bedeutet, Service- und Risikoziele festzulegen und nachzuweisen, dass das System sie erfüllt. Sie ist keine universelle Garantie oder einzelne Zertifizierung.

Autorisierung. Authentifizierte Identitäten und Berechtigungsprüfungen an einem vertrauenswürdigen Durchsetzungspunkt für jede geschützte Aktion und jedes Datenobjekt.
Datenintegrität und Recovery. Wo nötig transaktionales Verhalten, versionierte Änderungen, definierte Recovery-Ziele, geschützte Backups und getestete Wiederherstellung samt Abgleich.
Zuverlässigkeit. Kapazität, Fehlerbehandlung, Dependency-Verhalten, Deployment-Sicherheit und Recovery passend zu expliziten Servicezielen.
Sicherheit. Vertrauliche Zugangsdaten außerhalb nicht vertrauenswürdiger Clients, validierte Vertrauensgrenzen, gepflegte Komponenten und aus einem Bedrohungsmodell abgeleitete Kontrollen.
Observability. Logs, Metriken, Traces, Alerts und Aufbewahrung passend zu den Fehlern und Untersuchungen des Teams.
Support. Verantwortlichkeit, Runbooks, Eskalation und genug Audit-Kontext, um Vorfälle ohne Raten zu erklären.

Ein Prototyp kann nützliches Verhalten zeigen, ohne für all diese Bereiche Nachweise zu liefern. Deshalb ist die Demo ein Input für die Readiness-Entscheidung, nicht die Ziellinie.

Schritt 1: Wie riegelst du Auth und Datenzugriff ab?

Ein Login-Screen belegt den Authentifizierungsfluss, nicht die Autorisierung. Teste für jede geschützte Aktion und jedes Objekt, ob ein anderer Nutzer, Tenant, eine andere Rolle oder ID eine Ablehnung erhält. Clientseitiges Verbergen kann die Bedienbarkeit verbessern, darf laut OWASP aber nicht der entscheidende Zugriffsschutz sein.

Erzwinge Autorisierung an einer vertrauenswürdigen Service-Schicht, die geschützte Aktionen oder Daten kontrolliert. Das kann API, Gateway, Serverless Function oder Datenbank-Policy sein, nicht nur ein klassischer Server. Zentralisiere bei Multi-Tenant-Systemen Tenant- und Row-Isolation und teste Cross-Tenant-Zugriff direkt. Row-Level Security kann helfen, braucht aber korrekte Policies und Verifikation.

Schritt 2: Kannst du den Data-Layer betreiben und wiederherstellen?

Migriere einen Datendienst nicht allein deshalb, weil er über ein Prototyp-Tool verbunden wurde. Lovable dokumentiert verwaltete Backend-Integrationen und Lovable Cloud. Replit verweist auf persistente Datenbank- oder Speicherdienste, weil das Dateisystem veröffentlichter Apps nicht persistent ist. Behalte einen Dienst, wenn Eigentum, Zugriff, Kapazität, Retention, Export, Löschung, Backup und Recovery deinen Anforderungen entsprechen.

Versioniere Schemaänderungen, sofern die Plattform Migrationen unterstützt, und definiere Recovery-Ziele für Datenbanken, Objektspeicher, Identity-Konfiguration, Secrets und Infrastrukturzustand. Aktiviere die nötigen Backup- oder Point-in-Time-Kontrollen und teste Wiederherstellung samt Abgleich. Supabase dokumentiert ausdrücklich, dass ein Datenbank-Backup nicht Storage-Objekte oder jede Servicekonfiguration enthält. Teste deshalb den vollständigen Recovery-Umfang.

Schritt 3: Secrets und Umgebungen

Klassifiziere Zugangsdaten, bevor du sie verschiebst. Öffentliche Kennungen und veröffentlichbare Schlüssel können für nicht vertrauenswürdige Clients gedacht sein; privilegierte API-Keys, Service-Zugangsdaten, Signaturmaterial und Bearer-Tokens sind vertraulich. Speichere vertrauliche Werte im Backend-Secret-Speicher der Plattform oder einem freigegebenen Secret Manager, vergib Least Privilege und halte sie aus Bundles, Logs, Build-Artefakten, Prompts und Repository-Historie heraus.

Trenne Entwicklung, Test oder Staging und Produktion risikogerecht mit eigenen Zugangsdaten und passend isolierten Daten. Lovables Test- und Live-Umgebungen sind für neue Cloud-Projekte derzeit nicht verfügbar. Prüfe die Funktion am konkreten Projekt oder stelle die Trennung über Backend und Delivery-Workflow her. Behandle offengelegte vertrauliche Zugangsdaten als kompromittiert, widerrufe oder rotiere sie und prüfe nachgelagerte Tokens, Logs und Caches. Der Aufwand hängt von Zugangsdaten und Abhängigkeiten ab.

Schritt 4: Hosting, CI/CD, Rollbacks, Observability

Ein gebündelter Host ist nicht automatisch ungeeignet für Produktion. Lovable dokumentiert dauerhaftes Publishing, Custom Domains, Zugriffseinstellungen, Sicherheitschecks und externes Deployment über GitHub; Replit dokumentiert Autoscale- und Reserved-VM-Deployments. Prüfe je Plan Kapazität, Regionen, persistenten Speicher, Netzwerkkontrollen, Deployment-Identität, Umgebungstrennung, Domain-Eigentum, Backups, Rollback oder Forward Recovery, Support, Portabilität und Serviceziele. Wechsle nur, wenn die Plattform diese Anforderungen nicht erfüllt.

Automatisiere wiederholbare Build-, Test-, Freigabe- und Deployment-Schritte risikogerecht. Teste ein fehlgeschlagenes Release und den gewählten Rollback- oder Forward-Recovery-Pfad, statt eine nicht gemessene Recovery-Zeit zu versprechen. Ergänze Logs, Metriken, Traces, Error Tracking, Uptime- oder Synthetic Checks, Alerts und Runbooks. Schütze auch Observability-Daten, denn Logs können sensible Werte enthalten.

Schritt 5: Wann behältst du den generierten Code, und wann baust du neu?

Nicht der gesamte generierte Code muss weggeworfen werden, und nicht der gesamte ist es wert, behalten zu werden. Prüfe, wo die Probleme liegen: Manche Lücken lassen sich lokal beheben, andere überschreiten Datenmodell-, Sicherheits- oder Deployment-Grenzen und verlangen einen umfassenderen Ersatz.

Behalte das Fundament, wenn Datenmodell, Grenzen, Dependencies, Wartbarkeit, Testbarkeit und Deployment-Modell die Ziele mit angemessenen Änderungen erfüllen können. Ersetze oder baue eine Kernschicht neu, wenn eine Korrektur im Bestand mehr Migrationsrisiko, doppelte Nacharbeit oder langfristige Betriebskosten erzeugt als kontrollierter Ersatz. Entscheide anhand von Repository- und Architekturnachweisen, Dependency-Map, Migrationsplan, Abnahmetests, Rollback-Pfad und Lebenszykluskosten.

"Ein Prototyp ist wertvoller Nachweis, kein Beweis für Produktionsreife. Behalte, was die Ziele erfüllt, ersetze den Rest und entscheide aus Architektur und Tests statt aus dem Toolnamen."

Wie lange dauert es, und was kostet es?

Es gibt keine belastbare universelle Dauer oder Pauschale. Der Umfang hängt von Architektur, Code- und Dependency-Qualität, Migrationszwängen, Testabdeckung, Datensensibilität, Zahlungsflüssen, Integrationen, Regulierung, Exposition und Servicezielen ab. Ein enges internes Tool und ein öffentliches Produkt mit Zahlungen oder personenbezogenen Daten brauchen andere Nachweise und Maßnahmen.

Wir prüfen Repository, deployte Architektur, Datenflüsse, Plattformkonfiguration und vorhandene Nachweise vor der Schätzung. Das erste Ergebnis sollte zeigen, ob gezieltes Hardening, teilweiser Ersatz oder ein Core-Rebuild risikoärmer ist, mit sichtbaren Annahmen und Abnahmekriterien. Die detaillierte Version ist unser Software-QA-Service, die Fehlermuster behandeln wir in QA für KI-generierten Code.

Fazit

Ein schneller Prototyp ist wertvoller Nachweis, Produktionsreife aber eine separate risikobasierte Entscheidung. Behalte oder ersetze eine Schicht nicht wegen des Builder-Namens. Prüfe Autorisierung, Recovery, vertrauliche Secrets, Umgebungstrennung, Deployment-Sicherheit, Observability, Support und den genauen Plattformplan.

Dokumentiere Nachweise und nicht erfüllte Ziele und entscheide dann zwischen gezieltem Hardening, teilweisem Ersatz und Core-Rebuild. Nutze unabhängige Prüfung bei sensiblen Daten, Geld, privilegierten Aktionen oder sicherheitskritischen Folgen und prüfe neu, wenn Architektur oder Provider-Funktionen sich ändern.