Jedes Vibe-Coding-Pitch erwähnt Code-Ownership irgendwo im ersten Absatz. Export nach GitHub. Kein proprietäres Format. Nehmen Sie es mit. Das klingt wie das Gegenteil von Lock-in, und für den Teil Ihrer App, der nur aus React-Komponenten besteht, stimmt das meistens auch.
Der Teil, der es nie in den Pitch schafft, ist die Datenbank. Und genau dort lebt die eigentliche App.
Was “Export” wirklich exportiert
Bolt und Base44 bieten beide einen unkomplizierten GitHub-Sync für das Frontend, und Lovable macht dasselbe für seine React/TypeScript-Ausgabe. Wenn Ihre App eine Marketing-Seite oder ein statischer Prototyp ist, macht dieser Export fast alles aus, und Sie können das Repo an einen Entwickler übergeben und sauber aussteigen.
Business-Apps sind das nicht. Sobald Ihr Build Logins, Rollen und echte Datensätze hat, steckt das meiste, was es funktionieren lässt, nicht im Komponentenbaum, sondern im Schema, den Auth-Regeln und der dahinterliegenden Berechtigungslogik. Genau das ist die Ebene, die diese Plattformen am ungernsten aus der Hand geben.
Base44 macht das explizit statt implizit: Rezensenten stellen fest, dass der Frontend-Code nach GitHub exportiert wird, Datenbank und Backend aber vollständig auf Base44s Infrastruktur gehostet bleiben und nicht direkt geändert oder exportiert werden können. Ein Base44-Nutzer, der versuchte, seine eigenen Dateien von der Plattform zu bekommen, brachte es auf Reddit unverblümt auf den Punkt: “Ich sehe keine src-Dateien in den zugänglichen Dateien, also fürchte ich, ich müsste ein Jahr Builder-Tarif zahlen, nur um den Build von Base44 herunterzuladen. Das sind 480 $, was etwas absurd ist.” Technisch gesehen kann man gehen. Man zahlt nur erst ein Abo, um herauszufinden, mit was man geht.
Das Hotel-California-Problem
Die Beschwerden über Lovable gehen noch einen Schritt weiter, denn das Problem ist nicht nur, was nicht exportiert wird, sondern was sich ohne Nachfrage ändert. Ein Reddit-Thread, der in der Community zu einer Referenz geworden ist, beschreibt, wie Lovables KI eigenständig die private Supabase-Datenbank eines Nutzers ohne ausdrückliche Zustimmung zu Lovable Cloud migriert, und nennt die Plattform “ein Hotel California für Ihre Datenbank: Sie können einchecken, aber nie wieder gehen.”
Das ist ein anderer Fehlerfall als “der Export-Button fehlt”. Die Plattform verschiebt still und leise genau das, was man eigentlich exportieren müsste. Wenn Sie annahmen, Ihre Daten lägen in Ihrem eigenen Supabase-Projekt, weil das Tool sich so vermarktet, ist es genau die Art von Überraschung, die im Nachhinein zu einem warnenden Reddit-Thread wird, den andere Entwickler später finden, kurz bevor sie dieselbe Annahme treffen.
Base44s Backend-Lock-in kommt aus einer anderen Richtung zum gleichen Schluss: Ein Product-Hunt-Rezensent stellte fest, dass selbst dort, wo Frontend-Code sauber exportiert, Datenbank und Backend in Base44s geschlossener Infrastruktur gefangen bleiben, was eine echte Datenbankmigration verhindert. Zwei Plattformen, zwei Mechanismen, dasselbe Ergebnis: Der Teil der App, der Ihre echten Geschäftsdaten enthält, ist genau der Teil, den Sie nicht einfach mitnehmen können.
Warum sich das aufschaukelt, statt gleich zu bleiben
Am ersten Tag spielt das kaum eine Rolle, denn Tag eins ist eine Demo mit Beispieldaten. Es beginnt zu zählen, sobald die App echte Nutzer hat und das Schema über das hinausgewachsen ist, was ein einziger Prompt ursprünglich angelegt hat.
Schema-Schulden sind der Mechanismus, der aus “wir migrieren irgendwann” ein “wir sitzen fest” macht. Langjährige Lovable-Nutzer berichten, dass es zunächst gut funktioniert, die KI das Datenbankschema entwerfen zu lassen, aber nach sechs bis neun Monaten entstehen Schema-Schulden, die so gravierend sind, dass das Hinzufügen eines einzigen neuen Feldes das Umschreiben Dutzender nachgelagerter Workflows erfordern kann. An diesem Punkt bedeutet Migration nicht mehr, eine Tabelle zu kopieren, sondern ein System zu entwirren, das niemand vollständig dokumentiert hat, während es entstand. Dieselbe Recherche zeigt, dass erfahrene Entwickler inzwischen von Lovable abraten für alles, was länger als 18 bis 24 Monate laufen soll, und empfehlen, vorher auf einen codebasierten Stack umzusteigen, bevor sich diese Schulden weiter aufbauen.
Dazu kommt eine Plattform, die sich auch selbst unter Ihnen aktualisiert. Nutzer auf Lovable berichten, dass die eigenen Updates der Plattform regelmäßig bestehende Kunden-Apps kaputtmachen, so sehr, dass manche ihren Kunden inzwischen eine monatliche Wartungsgebühr berechnen, nur um die von der Plattform selbst verursachten Regressionen aufzufangen. Man ist nicht nur an die Datenbank gebunden. Man ist auch daran gebunden, den Schaden zu beheben, den der Anbieter verursacht, während man gebunden ist.
“Ich habe wirklich Angst vor Base44, weil ich das Fundament meines Geschäfts auf dieser Plattform baue… etwas funktioniert heute, und morgen nehmen sie es wieder weg.” - Base44-Nutzer, r/Base44
Was das Risiko tatsächlich verringert
Wir werden nicht so tun, als gäbe es eine Version von “gehosteter Plattform”, die null Lock-in bedeutet. Auch Softr ist gehostet, und wenn Sie Ihr Konto schließen, gehen Sie nicht mit einer portablen App nach Hause, genauso wenig wie bei Lovable oder Base44. Die ehrliche Frage lautet nicht “kann ich Lock-in ganz vermeiden”, sondern “wie viel meiner Daten bleibt erreichbar, während ich die Plattform noch nutze, und wie schlimm ist der Ausstieg, falls ich jemals einen brauche”.
Bei dieser Frage zählt der Mechanismus mehr als die Marketingzeile. Ein paar Dinge, die es sich lohnt zu prüfen, bevor Sie etwas Tragendes auf irgendeiner Plattform bauen:
- Kann ein externes Tool auf Ihre Daten zugreifen, ohne über die UI der App zu gehen? Softrs eigene Datenbank stellt einen MCP-Server (
mcp.softr.io) sowie eine REST-API bereit, sodass Tools wie Claude, Cursor oder ein Skript Ihr Schema in natürlicher Sprache lesen, schreiben oder umstrukturieren können, während Sie noch bauen. Softr stellt das direkt als Mittel gegen Lock-in dar, indem die Datenbank außerhalb einer einzigen Oberfläche zugänglich bleibt, was ein anderes Versprechen ist als “Sie können den Code irgendwann exportieren”. - Verschiebt die Plattform Ihre Infrastruktur still, ohne es Ihnen zu sagen? Genau das ist die Beschwerde über Lovable. Wenn Ihre Plattform als Teil einer KI-Aktion umverteilen kann, wo Ihre Daten liegen, fragen Sie nach, was das auslöst und ob Sie sich dagegen entscheiden können.
- Was kostet eine Schemaänderung nach sechs Monaten tatsächlich? Nicht am ersten Tag, wenn alles ein frisches KI-Gerüst ist, sondern nachdem echte Nutzung die Daten geformt hat. Schema-Schulden sind die langsame Version von Lock-in, und sie tauchen auf keiner Preisseite auf.
Wenn die App wirklich nur ein Prototyp oder ein persönliches Projekt ist, sollte Sie nichts davon abhalten, sie an diesem Wochenende zu vibe-coden, exportierbarer Code inklusive. Aber wenn es sich um ein Kundenportal, ein internes Tool oder irgendetwas mit echten Nutzern und echten Daten handelt, sind das Day-Two-Problem und das Lock-in-Problem dasselbe Problem unter zwei Namen: Die Verrohrung, an die Sie am ersten Tag nicht gedacht haben, ist genau das, was am zweihundertsten Tag am schwersten zu verschieben ist. Werfen Sie vor der Wahl eines Fundaments, das Sie nicht einfach verlassen können, einen Blick auf unser Ranking für Kundenportale.