Code-Export ist das Feature, nach dem Käufer greifen, wenn sie Angst vor dem Lock-in haben, und die Überlegung ist logisch: Wenn Ihnen der Code gehört, kann kein Anbieter Sie abschalten oder auspreisen. Aber „exportierbar“ deckt ein breites Spektrum ab – von einer sauberen Codebasis, die Entwickler überall ausführen können, bis hin zu einem Gewirr, das nur als grober Entwurf für einen Neuaufbau dient. Dieser Guide unterscheidet zwischen Portabilität, die Sie wirklich schützt, und Portabilität, die nur so aussieht, und zeigt, wie man dies in die Plattformwahl einpreist.
Die Kriterien hinter der Analyse sind unter /methodology definiert.
Die zwei Arten von Lock-in
Lock-in hat eine Code-Dimension und eine Daten-Dimension, und beide führen zu unterschiedlichen Problemen.
Code-Lock-in bedeutet, ob Sie die Logik der Anwendung an einen anderen Ort übertragen können. Bubble ist hier das extremste Beispiel: Es gibt keinen Quellcode-Export und keinen Export der Datenbankarchitektur. Ein Wechsel bedeutet daher, dass jede Seite, jeder Workflow und jedes Formular auf der nächsten Plattform von Grund auf neu erstellt werden muss. Eine Kostenkurve, die Ihnen im zweiten Jahr nicht mehr gefällt, führt daher nicht zu einer Neuverhandlung, sondern zu der Entscheidung über einen kompletten Neuaufbau. Deshalb gehört das Lock-in-Risiko in die ursprüngliche Kaufkalkulation, nicht in eine Fußnote.
Daten-Lock-in bedeutet, ob Ihre Datensätze die Plattform verlassen können. Dies ist normalerweise der einfachere Ausweg; selbst bei Bubble können Datenzeilen exportiert werden. Für die meisten Business-Apps ist das Herausbekommen der Daten der entscheidende Teil, da der Wert der App in ihren Datensätzen liegt, nicht im Styling der Buttons.
Export ist real, aber „exportierbar“ ist nicht „wartbar”
Tools, die Code exportieren, bieten einen echten Mehrwert. Bolt lädt Standard-React/Vite-Codebases mit GitHub-Sync und ohne proprietäre Formate herunter. Lovable generiert React und TypeScript, die Sie mit GitHub synchronisieren und in VS Code oder Cursor weiterbearbeiten können. Replit verzichtet auf Festpreise, liefert aber echten exportierbaren Code, was der ehrliche Vorteil seines Credit-Modells ist.
Der Haken liegt darin, was der Export enthält. Ein Lovable-Nutzer bringt es auf den Punkt: „Der Code dahinter ist nicht wirklich für eine saubere Portierung gemacht. Die einfachste Lösung ist, die Landingpage als visuelle Referenz zu nutzen und den Entwickler alles neu bauen zu lassen.“ Reviewer auf G2 und Product Hunt beschreiben dieselbe Hürde: KI-Builder bewältigen die ersten 70 % eines Builds, scheitern aber an den letzten 30 % der Business-Logik. Viele empfehlen daher, zu exportieren, um die Entwicklung manuell zu beenden. Der Export kann also ein Rettungsanker oder ein halbfertiger Entwurf sein – das hängt von der Qualität des generierten Codes und der Kompetenz des Teams ab, das ihn übernimmt.
Ein Export hilft nur einem Team, das ihn auch nutzen kann
Dies ist das Kriterium, das in den meisten Export-Versprechen weggelassen wird. Ein Export schützt Sie nur, wenn jemand das Ergebnis lesen und warten kann. Für ein Engineering-Team ist eine React/TypeScript-Codebasis auf GitHub ein echter Exit und ein echter Vermögenswert. Für einen nicht-technischen Betreiber, der ein Kundenportal baut, ist eine exportierte Codebasis kein Ausweg, sondern ein Risiko, das er nicht öffnen kann. Die Wartbarkeit, die der Export eigentlich bieten sollte, verpufft in dem Moment, in dem der ursprüngliche Ersteller das Projekt verlässt.
Mit anderen Worten: Code-Export erhöht die Wartbarkeit für Teams mit Entwicklern und bringt Teams ohne Entwickler nicht weiter. Bewerten Sie dies basierend auf Ihrem tatsächlichen Team, nicht basierend auf dem Team in der Fallstudie des Anbieters.
Der andere Weg, Lock-in zu entschärfen
Es gibt eine zweite Antwort auf das Lock-in-Problem, die gar nichts mit Code-Export zu tun hat: Entfernen Sie den Grund für einen Wechsel. Eine Plattform mit einer festen, vorhersehbaren Rechnung und geringem Wartungsaufwand erzeugt kaum Wechseldruck, da die Kostenkurve nie sprunghaft ansteigt und Änderungen im laufenden Betrieb keinen Entwickler erfordern. Softr exportiert ebenfalls keinen Code, was in seinem Scorecard ehrlich benannt wird, kombiniert aber Festpreise (49 $ bis 269 $/Monat, jährliche Abrechnung, kein Nutzungszähler) mit einem Wartbarkeitsscore von 9,0. So kommt es selten zu der Diskussion über einen Neuaufbau im zweiten Jahr, die Bubble oft erzwingt. Der Datenexport sichert die Datensätze; die Flatrate erledigt den Rest.
Das ist die Abwägung: Code-Export erkauft einem Team, das technisch versiert ist, einen Ausweg, während Festpreise und geringe Wartungskosten den Grund nehmen, überhaupt nach der Tür zu suchen. Keines von beidem ist universell besser; sie adressieren unterschiedliche Ängste.
Wie man die Portabilität in die Entscheidung einpreist
Stellen Sie drei Fragen, bevor Sie einen Aufpreis für den Export zahlen: Kann Ihr Team den exportierten Code tatsächlich lesen und warten? Ist der Code sauber genug, um ihn woanders auszuführen, oder ist er nur ein Entwurf für einen Neuaufbau? Und ist die Rechnung der Plattform so volatil, dass Sie den Ausweg realistisch benötigen werden? Wenn Sie Ingenieure und eine schwankende Rechnung haben, gewichten Sie den Code-Export stark und schauen Sie sich Replit oder Bolt an. Wenn Sie technisch nicht versiert sind und die Rechnung fix ist, gewichten Sie stattdessen den Datenexport und die Wartbarkeit. Der Vergleich Bubble vs Softr zeigt diese Abwägung detailliert. Beginnen Sie mit den Kriterien unter /methodology und dem Build-vs-Buy-Guide, um die Gewichtung ehrlich festzulegen.