Jedes Vibe-Coding-Tool mit einem GitHub-Button sagt eine Version desselben Satzes: “Der Code gehört Ihnen, kein Lock-in.” Er steht auf der Preisseite, in der FAQ, meist direkt neben einem Häkchen-Symbol. Behandeln Sie diesen Satz als eine zu prüfende Behauptung, nicht als akzeptierte Tatsache, denn genau in der Lücke zwischen “Sie können eine Datei exportieren” und “Sie können gehen” steckt der Großteil des tatsächlichen Lock-ins.
Was “Export” still verschweigt
Eine Codebasis ist nicht eine einzelne Sache. Sie besteht aus Frontend, Backend und Datenbank, und ein Tool kann “Code-Export” bewerben, obwohl damit nur der erste der drei gemeint ist. Base44 dokumentiert diese Trennung klar: Der Frontend-Quellcode wird nach GitHub exportiert, aber die Backend-Logik wird vollständig auf Base44s eigener Infrastruktur gehostet und verwaltet, in eigenen Materialien beschrieben als nicht direkt veränderbar oder exportierbar. Product-Hunt-Bewertungen zu Base44 bestätigen dasselbe Muster aus Nutzersicht: Datenbank und Backend bleiben in der geschlossenen Infrastruktur der Plattform gefangen, obwohl das Frontend sauber abgeht. Ein Reddit-Nutzer, der die Plattform tatsächlich verlassen wollte, berichtete, ihm sei ein Jahr des 40 $/Monat teuren Builder-Plans genannt worden, 480 $, nur um Zugriff auf die Quelldateien zu bekommen, nachdem seine App wiederholt in einer Debugging-Schleife kaputtgegangen war.
Zite umgeht die Frage komplett. Es bietet keinen GitHub-Sync und überhaupt keinen Code-Export, was seine eigenen Nutzer auf Reddit als echtes Hindernis bei Migration oder Übergabe an einen Entwickler bemängeln. Ohne Export-Button beginnt das Gespräch über “der Code gehört Ihnen” gar nicht erst.
Exportierter Code, den man nicht will
Die andere Hälfte der Illusion besteht darin anzunehmen, dass exportierter Code auch Code ist, den jemand freiwillig warten würde. Lovable exportiert tatsächlich standardmäßiges React und TypeScript und synchronisiert für die lokale Entwicklung mit GitHub, was eine echte Stärke ist. Aber die eigenen Nutzerberichte beschreiben das Ergebnis als unübersichtlich und nicht skalierbar: Ein Builder fasste es so zusammen, dass es als visuelle Referenz tauge, aber nichts sei, das man sauber übertragen könne, und empfahl, dass ein Entwickler die App in einem echten Stack neu aufbaut, statt die generierte zu übernehmen. Das passt zu dem breiteren Muster, das diese Seite verfolgt: die Fix-Loop-Falle hinterlässt doppelte Hilfsfunktionen und Flickwerk-Styles, weil das Modell die gesamte Codebasis, die es bearbeitet, nicht überblicken kann. Der Export übergibt Ihnen dieses Flickwerk mit angehängter GitHub-URL, keine Codebasis, die ein neuer Entwickler ab Tag eins übernehmen kann.
Die Datenbankseite verschärft das Problem. Lovable-Nutzer auf Reddit haben die Plattform als “Hotel California” für Ihre Datenbank bezeichnet: Man kann einchecken, aber mehrere Berichte beschreiben, dass die KI eigenständig eine Backend-Migration eingeleitet hat, vom privaten Supabase-Projekt eines Builders zu Lovables eigenem verwalteten Supabase, ohne ausdrückliche Zustimmung. Wie auch immer der Frontend-Export aussieht, das Backend samt Schema ist ein separates Migrationsprojekt, eines, das die KI entworfen hat und das der Builder womöglich nie vollständig geprüft hat.
Die Tools, die es richtig machen, und was “richtig” kostet
Bolt und v0 sind die ehrlichen Gegenbeispiele und verdienen es, als solche genannt zu werden. Bolt dokumentiert direkten Codebasis-Download plus automatische GitHub-Synchronisierung, die eine standardmäßige React/Vite-Codebasis ohne proprietäre Formate ergibt. v0s eigene Materialien beschreiben Exporte als sauberen, inspizierbaren React- und TypeScript-Code ohne proprietäre Schichten oder Sperrmechanismen. Beide Behauptungen kommen dem näher, was “kein Lock-in” eigentlich bedeuten sollte: Das, was die Plattform verlässt, ist auch das, worauf man tatsächlich weiterbauen möchte.
Aber beachten Sie, was diese Ehrlichkeit nicht beseitigt. Ein sauberer Export übergibt Ihnen trotzdem eine Codebasis, geschrieben von einem Modell mit begrenztem Kontextfenster, weiterhin dem Day-Two-Problem unterworfen: Sie läuft heute, und ob sie sechs Monate echter Änderungen übersteht, hängt davon ab, ob jemand prüft, was darin steckt. Portabler Code ist notwendig, um Lock-in zu vermeiden. Er reicht nicht aus, um die Wartungsrechnung zu vermeiden.
Die Frage hinter dem Häkchen
Bevor Sie einer Export-Behauptung vertrauen, trennen drei Fragen Marketing von Realität. Erstens, was tatsächlich die Plattform verlässt: nur das Frontend, oder Backend und Datenbank mit dazu. Zweitens, wer es lesen kann ohne Hilfe des Tools, denn Code, den niemand im Team warten kann, ist nur dem Namen nach portabel. Drittens, was Builder berichtet haben, die es versucht haben, denn ein Reddit-Thread über eine Ausstiegsgebühr von 480 $ sagt mehr aus als ein Häkchen auf einer Preisseite.
Für Business-Apps, Portale, interne Tools, CRMs gibt es einen strukturellen Weg, die ganze Frage zu umgehen: dort bauen, wo “Export” von Anfang an gar kein Code ist. Bei Softr sind Authentifizierung, Berechtigungen und Datenstruktur Plattform-Konfiguration, und die zugrunde liegenden Daten können in Quellen liegen, die Sie bereits kontrollieren (Airtable, Google Sheets oder SQL), oder über Softrs eigene Datenbank per API und MCP erreicht werden, sodass ein Builder nicht auf einen GitHub-Export warten muss, um nicht von der Infrastruktur eines einzelnen Anbieters abhängig zu sein. Das ist ein anderer Kompromiss als Code-Eigentum, kein Ersatz dafür: Man tauscht “ich kann den Code exportieren” gegen “die Daten waren von Anfang an nie gefangen.” Welcher Kompromiss richtig ist, hängt davon ab, ob die App einen Entwickler braucht, der eigene Logik besitzt, was für Cursor oder Bolt spricht, oder ob sie einfach ohne funktionieren muss.