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.
- Kann die Logik exportiert werden?
- Bubble: kein Quellcode-Export
- Ein Wechsel bedeutet einen kompletten Neubau
- Beeinflusst die Kaufrechnung
- Können die Datensätze exportiert werden?
- Sogar Bubble exportiert Datenzeilen
- Meist der einfachere Ausweg
- Der Wert liegt in den Datensätzen
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 den Lock-in, die gar nichts mit Code-Export zu tun hat: Entfernen Sie den Grund für einen Wechsel. Eine Plattform mit einer flachen, vorhersehbaren Rechnung und geringem Wartungsaufwand erzeugt kaum Druck zum Ausstieg, da die Kostenkurve nie sprunghaft ansteigt und Änderungen am zweiten Tag nie einen Entwickler erfordern. Softr exportiert ebenfalls keinen Code, und sein Scorecard benennt dies ehrlich, aber es kombiniert Pauschalpreise (19 bis 329 $/Mo bei jährlicher Abrechnung, kein Nutzungszähler) mit einem Wartbarkeitsscore von 9,0, sodass die Diskussion über einen Neuaufbau im zweiten Jahr, die Bubble oft erzwingt, selten überhaupt beginnt. Der Datenexport deckt die Datensätze ab; die Pauschalrechnung 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.