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

Eine KI-IDE wie Lovable, Cursor, Claude Code, Bolt, v0 oder Replit bringt dich in Tagen zu einem klickbaren Produkt. Das ist echter Fortschritt, und es ist auch der einfache Teil. Die Distanz zwischen "die Demo läuft" und "echte Nutzer können sich darauf verlassen" ist ein eigenes Projekt mit eigenem Umfang, und so zu tun, als wäre es das nicht, ist genau, wie Launches schiefgehen. Das ist die Checkliste, die wir fahren, wenn ein Prototyp produktionsreif werden muss.

Nichts davon ist ein Vorwurf an die Tools. So fangen wir auch an. Es ist eine Karte der Arbeit, die nicht von allein passiert, damit du sie einplanen kannst, statt sie während eines Incidents zu entdecken.

Was "Produktion" tatsächlich heißt

Eine Demo beweist die Idee. Produktion trägt das Gewicht. Der Unterschied ist nicht Politur, sondern eine Reihe von Garantien, die niemand sieht, bis sie fehlen.

• Auth, die hält. Echte Accounts, echte Sessions und eine harte Regel, dass ein Nutzer nicht an die Daten eines anderen kommt.
• Datenintegrität. Schreibvorgänge, die entweder durchlaufen oder sauber zurückrollen, und ein Store, dem du auch nächsten Monat noch vertraust.
• Uptime. Ein Deploy, der einen Neustart, eine Lastspitze und ein schlechtes Release ohne manuelle Rettung übersteht.
• Security. Keine Keys im Browser, keine offenen Endpunkte, keine Dependency, die du nicht angeschaut hast.
• Observability. Wenn um 2 Uhr nachts etwas bricht, erfährst du es von einem Tool, nicht von einem Kunden.
• Support. Eine Möglichkeit, "was ist mit meiner Bestellung passiert" zu beantworten, ohne zu raten.

Ein Prototyp kann jeden einzelnen dieser Punkte überspringen und trotzdem perfekt demonstrieren. Genau deshalb ist die Demo nicht die Ziellinie.

Schritt 1: Auth und Datenzugriff abriegeln

Das ist das Erste, was wir prüfen, und das Häufigste, was falsch ist. KI-IDEs sind sehr gut darin, einen Login-Screen zu bauen, und sehr schlecht darin, durchzusetzen, was nach dem Login passiert. Das Frontend versteckt den Button, aber die API antwortet weiter jedem, der fragt.

Jede Zugriffsprüfung muss auf dem Server liegen. Verlager die Autorisierung komplett aus dem Client und setze sie dort durch, wo Daten gelesen und geschrieben werden. Wenn dein Produkt multi-tenant ist, isoliere pro Tenant oder pro Zeile, sodass ein Account physisch nicht die Datensätze eines anderen abfragen kann, idealerweise auf Datenbankebene statt in App-Logik, an die du auf jedem Endpunkt denken musst. Ein Frontend-Check ist ein UX-Komfort. Er ist keine Security, und war es nie.

Schritt 2: Deinen Data-Layer besitzen

Viele Prototyp-Tools geben dir einen bequemen geteilten oder Wegwerf-Datenstore, damit du loslegst. Das ist großartig für eine Demo und falsch für Produktion. Du kontrollierst weder die Backups noch die Limits noch die Lebensdauer, und "die Daten wurden zurückgesetzt" ist kein Satz, den du einem zahlenden Nutzer sagen willst.

Wechsel zu einer echten managed Datenbank, die dir gehört, in den meisten Fällen Postgres. Bring dein Schema unter versionierte Migrationen, sodass Änderungen wiederholbar und reviewbar sind, statt in ein Dashboard geklickt. Schalte automatische Backups ein und teste einen Restore tatsächlich einmal, denn ein Backup, das du nie zurückgespielt hast, ist eine Hoffnung, kein Backup. Das ist meist der unspektakulärste Schritt und der, der dir den schlimmsten Tag erspart.

Schritt 3: Secrets und Umgebungen

Prototypen leaken Keys. Das Tool schreibt einen API-Key inline, damit das Beispiel läuft, und er landet im Client-Bundle oder in der Repo-Historie, wo ihn jeder lesen kann. Die erste Aufgabe hier ist, jeden Secret vom Client zu holen und auf den Server zu legen, hinter dein eigenes Backend.

Dann trenn deine Umgebungen. Dev, Staging und Produktion sollten eigene Keys und eigene Daten haben, sodass ein Test nie einen echten Kunden berührt und ein Fehler im Staging niemandem etwas in Rechnung stellt. Und rotier alles, was je exponiert war. Ein Key, der in Client-Code oder einem öffentlichen Commit saß, ist kompromittiert, ob du Beweise für eine Nutzung hast oder nicht. Ihn zu rotieren kostet eine Stunde. Anzunehmen, dass alles okay ist, kann viel mehr kosten.

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

Der Prototyp-Host, der mit deiner KI-IDE mitkam, ist zum Zeigen gebaut, nicht zum Betreiben. Wechsel zu einem echten Deployment-Setup, bevor du dich darauf verlässt. Das heißt: eine Pipeline, die auf einen Push baut und ausliefert, eine Möglichkeit, in Sekunden auf die letzte gute Version zurückzurollen, und einen Staging-Schritt, sodass Änderungen gesehen werden, bevor Nutzer sie sehen.

Dann füg Augen hinzu. Error-Tracking, das dir sagt, wenn etwas wirft, einfaches Uptime-Monitoring und genug Logging, um im Nachhinein "was ist passiert" zu beantworten. Das Ziel ist einfach: Von einem Problem solltest du aus deinem Tooling erfahren, nicht aus einer wütenden Nachricht. Ohne diesen Layer fliegst du blind, und das erste Anzeichen für Ärger ist ein Nutzer, der schon abgesprungen ist.

Schritt 5: Die Behalten-oder-neu-bauen-Entscheidung

Nicht der gesamte generierte Code muss weggeworfen werden, und nicht der gesamte ist es wert, behalten zu werden. Die ehrliche Antwort ist, dass es darauf ankommt, wo die Probleme sitzen. Oberflächliche Lücken sind billig auf dem zu schließen, was du hast. Fundamentale nicht.

Behalte das Fundament, wenn das Datenmodell solide ist, die Struktur lesbar ist und die Lücken die vorhersehbaren von oben sind: Auth, Validierung, Error-Handling, Secrets. Das sind additive Fixes auf einer ordentlichen Basis. Bau den Kern neu, wenn das Datenmodell auf eine Weise falsch ist, von der alles andere abhängt, oder wenn dasselbe kaputte Muster über die ganze Codebasis kopiert wurde, sodass jeder Fix hundertmal gemacht werden muss. Ein Fundament zu flicken, das neu gegossen werden muss, ist der teuerste Weg, Geld zu sparen, und das sagen wir beim ersten Telefonat, statt dir den langen Umweg zu berechnen.

"Der Prototyp war nie das Projekt. Zu einer Demo zu kommen ist eine Aufgabe und in Produktion zu kommen eine andere, und die zweite wird nicht billiger, weil die erste schnell war."

Wie lange und wie viel

Aus Erfahrung läuft ein fokussierter Hardening-Durchgang an einem typischen KI-gebauten Prototyp ein bis drei Wochen. Das ist eine Spanne, kein Angebot, und sie bewegt sich aus zwei Gründen: wie viel echtes Geld oder sensible Daten das Produkt berührt, und wie weit das Tool gelaufen ist, ohne dass jemand gesteuert hat. Ein read-only internes Tool sitzt am kurzen Ende. Ein Produkt, das Zahlungen annimmt und personenbezogene Daten speichert, sitzt am langen Ende und braucht vielleicht mehr.

Was wir nicht tun, ist dir eine präzise Zahl zu geben, bevor wir hingeschaut haben. Wer eine fixe Summe für eine Codebasis nennt, die er nicht gesehen hat, rät, und der Tipp ist immer optimistisch. Wir scopen es nach einem ersten Blick, und wenn die ehrliche Antwort "den Kern neu bauen" ist, hörst du das zuerst, nicht in Woche drei. Die detaillierte Version dieser Arbeit ist unser Software-QA-Service, und die Fehlermuster dahinter behandeln wir in QA für KI-generierten Code.