Von Lovable zu Claude Code oder Cursor: wann und wie

Am Anfang ist Lovable genau richtig: Du beschreibst, was du willst, und siehst es sofort in der Vorschau. Irgendwann taucht aber die Frage auf, ob du mit Claude Code oder Cursor weiterbauen solltest. Vielleicht willst du Änderungen genauer kontrollieren. Vielleicht soll ein Entwickler mal draufschauen. Oder du willst einfach eine eigene Kopie deines Codes haben. Die gute Nachricht: Wechseln heißt nicht, Lovable sofort zu verlassen. Die Brücke dazwischen heißt Git-Sync.

Woran du merkst, dass der eigene Editor dran ist

Lovable nennt in seiner Dokumentation selbst die Gründe, ein Projekt mit GitHub zu verbinden. Prüf, ob einer davon auf dich zutrifft:

• Du willst eine eigene Sicherungskopie deines Codes.
• Du willst Änderungen in Pull Requests prüfen, bevor sie live gehen.
• Du willst neue Funktionen auf einem Branch testen, ohne das laufende Produkt zu gefährden.
• Du willst lokal mit deinem eigenen Editor oder Coding-Assistenten arbeiten.
• Du willst mit Entwicklern zusammenarbeiten oder später woanders deployen.

Trifft nichts davon zu, gibt es keinen Grund zur Eile. Lovable empfiehlt für die meisten Apps, alles auf der eigenen Plattform zu lassen. Wenn du dagegen kurz vor dem Launch eines Bezahl-Produkts stehst, wird die eigene Kopie wichtiger. Warum der Code-Export bei der Tool-Wahl zählt, steht auch im Vergleich Lovable, Bolt oder Replit fürs Bezahl-Produkt.

So funktioniert die Brücke: Git-Sync

Git-Sync hat zwei Ebenen. Zuerst verbindest du deinen Workspace mit einem GitHub-Konto. Danach verknüpfst du ein einzelnes Projekt mit einem Repository. Lovable legt dabei ein neues Repository an, das standardmäßig privat ist.

Ab dann läuft der Abgleich in beide Richtungen. Was du in Lovable änderst, landet als Commit auf GitHub. Was du auf den synchronisierten Branch pushst, erscheint in Lovable. Wichtig: Lovable bearbeitet immer nur einen Branch, meist main. Commits auf anderen Branches sieht Lovable erst nach einem Merge.

Damit bekommst du ein hybrides Setup. Du kannst große Umbauten lokal mit Claude Code machen und kleine Oberflächen-Änderungen weiter in Lovable. Claude Code liest laut Anbieter deine Codebasis, bearbeitet Dateien und führt Befehle aus, im Terminal, im Editor, in der Desktop-App oder im Browser.

Die vier Stolperfallen beim lokalen Arbeiten

Gleiche Datenbank, echte Daten. Bei Projekten mit dem eingebauten Backend steckt die Adresse deines Backends in der .env-Datei. Startest du die App lokal, liest und schreibt sie dieselbe Datenbank wie deine Live-App. Leg also Testkonten und Testdatensätze an. Ein Branch gibt dir keine eigene Datenbank.

Login lokal. Ein Anmeldedienst leitet nur auf Adressen weiter, die er kennt. Deine lokale Adresse musst du dort als Redirect-URL eintragen. Secrets, die du in Lovable hinterlegt hast, liegen nicht im Repository.

KI-Funktionen und Connectors. Bei neueren Lovable-Apps, die auf TanStack Start laufen, läuft der Server-Code lokal auf deinem Rechner. Aufrufe über Lovable AI oder App-Connectors schlagen dort fehl. Teste sie in der Lovable-Vorschau oder in der veröffentlichten App.

Backend-Änderungen deployen sich nicht von selbst. Änderst du lokal eine Edge Function oder legst eine Migration an, führt Lovable sie beim Sync nicht automatisch aus. Bitte Lovable im Projekt-Chat, die Funktion zu deployen, oder ändere die Datenbankstruktur über den Chat oder den SQL-Editor.

Die Regeln für die Übergabe

Lass Lovable auf main und arbeite lokal auf einem Feature-Branch. So landet ungeprüfte Arbeit nicht im Projekt. Bevor du klonst oder mergst, warte, bis keine Lovable-Änderung mehr läuft, und prüf die Sync-Status-Karte. Kein Force-Push, kein Rebase, kein Squash auf dem synchronisierten Branch. Willst du etwas zurücknehmen, leg einen Commit an, der die Änderung rückgängig macht.

Laufen beide Seiten auseinander, schiebt Lovable seine Änderungen auf einen separaten Branch namens lovable-sync. Ersetzt ein Push die Arbeit von Lovable, sichert Lovable vorher eine Kopie, die nur der Projekt-Owner wiederherstellen kann.

Nach dem Merge: Sag Lovable im Chat, was sich geändert hat, damit die nächste Änderung darauf aufbaut. Und denk dran, dass ein Merge deine Live-App nicht ändert. Erst ein erneutes Veröffentlichen bringt die Änderung zu deinen Nutzern.

Was das für deinen Launch bedeutet

Der Wechsel in Claude Code oder Cursor ist keine Mutprobe, sondern eine Arbeitsteilung. Der wichtigste Schritt ist der erste: dein Projekt mit GitHub verbinden, bevor du es brauchst. Lovable schlägt selbst vor, das vor einem Produktiv-Setup einmal durchzuspielen: Projekt synchronisieren, lokal starten, eine Kopie testweise auf einem eigenen Host deployen.

Wer Lovable komplett verlässt, übernimmt laut Lovable vieles selbst: Hosting, Zertifikate, Backups, Zugriffsrechte, Login, Secrets, Monitoring und Sicherheitsprüfungen. Das ist ein großer Schritt. Für die meisten Gründer reicht vor dem Launch das hybride Setup. Bevor du lokal Daten anfasst, lohnt ein Blick auf den Zwei-Konten-Test, und für den Rest die Launch-Checkliste.

Deine To-dos für diese Woche: GitHub verbinden. Prüfen, ob das Repository privat ist. Einmal lokal klonen und die App starten, nur mit Testkonto. Und notieren, welche Funktionen nur in Lovable selbst laufen.

Fazit

Lovable und Claude Code oder Cursor schließen sich nicht aus. Über Git-Sync baust du in beiden, solange du die Regeln einhältst: Lovable auf main, du auf einem Feature-Branch, Testdaten statt echter Daten, Merge statt Force-Push.

Du stehst an genau diesem Übergang und willst wissen, wie dein Produkt sauber bis zum Launch kommt? Trag dich in die Warteliste ein und schildere deine Idee – du bekommst eine ehrliche Einschätzung, ob sie zum geplanten Bootcamp passt.