Sie sollten gehen können. Das hier nehmen Sie genau mit

White Label / Code-Export

Die meisten Website-Builder lassen Sie irgendetwas exportieren: eine XML-Datei mit Beiträgen, einen Ordner mit HTML, eine CSV-Datei mit Seiten. Nur wenige lassen Sie mit einer Website gehen, die noch funktioniert. Bei We.Inc ist jede Website ein echtes React-Projekt, und der Code gehört Ihnen zum Herunterladen oder zum Übertragen nach GitHub. Diese Seite ist die Antwort für den Einkauf: was Sie bekommen, wie Sie es vor der Unterschrift testen und was nicht dazugehört.

Demo buchen · Die Preise richten sich nach deinem Volumen und Setup, und deinen genauen Preis erfährst du im Gespräch. 0% Transaktionsgebühr.

Aktualisiert: 25. Oktober 2026

Kurz gesagt

Warum Lock-in die erste Frage des Einkaufs ist

Wer schon einmal von einem gehosteten Builder migriert ist, kennt das Muster. Der Anbieter erhöht die Preise oder stellt ein Produkt ein; der Export entpuppt sich als Text ohne Layout; die Agentur baut jede Website von Hand neu und trägt die Kosten. Deshalb schreiben Einkäufer in Behörden und größeren Organisationen inzwischen Ausstiegsklauseln in den Vertrag. Unser Leitfaden zum Ausstiegsplan für Website-Anbieter behandelt diese Klauseln. Diese Seite zeigt, was das Produkt Sie tatsächlich mitnehmen lässt.

Woraus eine We.Inc Website besteht

Eine auf We.Inc gebaute Website, ob per KI, aus einer Vorlage oder von Hand, ist Quellcode: React-Komponenten in TypeScript, gestaltet mit Tailwind, gebündelt mit Vite. Dieselben Dateien, die der Editor zeigt, sind die Dateien, die Sie exportieren. Es gibt keine versteckte Layout-Datenbank, von der der Code abhängt.

Code-Bereich im We.Inc Editor mit dem Dateibaum des Projekts und dem Quelltext der Hero-Komponente sowie einer Schaltfläche Herunterladen

*Der Code-Bereich: der echte Dateibaum und Quelltext einer Kundenwebsite. Herunterladen erzeugt ein ZIP des Projekts.*

Nahansicht des Code-Bereichs mit dem Quelltext von Hero.tsx und Importen aus framer-motion und dem Content-Modul

*Der Quelltext des Hero-Bereichs. Text, den Kunden visuell bearbeiten, wird in diese Dateien zurückgeschrieben.*

Drei Wege hinaus

WegWas Sie bekommenWer ihn nutzen kannGeeignet für
ZIP herunterladenDas ganze Projekt, ohne reine Builder-DateienJeder mit der Berechtigung „Code ansehen“ für diese WebsiteÜbergabe an den Entwickler eines Kunden, Archivierung bei Vertragsende
Nach GitHub exportierenEin neues Repository mit dem Projekt, standardmäßig privatProjektinhaber, mit verbundener GitHub-App oder Personal Access TokenTeams, die eine Versionshistorie außerhalb von We.Inc möchten
Zwei-Wege-GitHub-SyncAus dem Builder pushen, in GitHub gemachte Änderungen zurückholenProjektinhaber, nur höhere Tarife (serverseitig geprüft)Entwickler, die zwischen KI- und visuellen Bearbeitungen in eigenen Tools arbeiten
Dialog Projekt exportieren mit den Tabs GitHub, ZIP, Vercel und Domain, einem Feld für den Repository-Namen und einem Kontrollkästchen Privates Repository

*Der Export-Dialog. Ein Repository-Name, eine Option für ein privates Repository und daneben ein ZIP-Tab.*

Was aus dem ZIP entfernt wird, und warum

Solange eine Website im Editor ist, enthält sie zwei Helfer, die nur innerhalb von We.Inc Sinn ergeben: ein kleines Build-Plugin, das Elemente markiert, damit der visuelle Editor sie findet, und eine Vorschau-Brücke, über die der Editor mit der Vorschau kommuniziert. Keines davon tut anderswo etwas, und die Brücke wäre auf fremdem Hosting ein Risiko. Das ZIP entfernt beide und löst das Plugin aus der Build-Konfiguration, sodass das exportierte Projekt mit einem einfachen npm install && npm run build baut. Der GitHub-Sync behält sie, denn ein Sync, der eine Konfiguration ohne das Plugin zurückholt, würde die visuelle Bearbeitung für diese Website abschalten.

Was NICHT mit dem Code mitkommt

Seien Sie Ihren Kunden gegenüber ehrlich mit dieser Liste. Genau hier gehen Migrationen schief.

Testen Sie es vor der Unterschrift: eine 30-minütige Ausstiegsübung

Machen Sie das während der Evaluierung, nicht am Vertragsende.

  1. Bauen Sie eine realistische Website auf einem Demo-Konto (eine Vorlage genügt).
  2. Laden Sie das ZIP aus dem Code-Bereich herunter.
  3. Auf einem sauberen Rechner: entpacken, npm install ausführen, dann npm run build.
  4. Stellen Sie den Build-Ordner über ein beliebiges statisches Hosting bereit und klicken Sie jede Seite an.
  5. Notieren Sie alles, was einen We.Inc Dienst aufruft (Formulare, Shop, Anmeldung), und entscheiden Sie, was es ersetzen würde.
  6. Exportieren Sie in ein privates GitHub-Repository und prüfen Sie, ob die Dateien übereinstimmen.
  7. Tragen Sie das Ergebnis mit dem Testdatum in Ihren Ausstiegsplan ein.

Wenn ein Schritt fehlschlägt, sprechen Sie es im Demo-Gespräch an. Wir wissen es lieber.

Steuern, wer Code sieht

Nicht jeder Kunde sollte Quelldateien sehen; manche werden verwirrt, einige machen etwas kaputt. „Code ansehen“ ist ein Schalter pro Kunde, mit einem Standard auf Markenebene, der sich pro Kunde überschreiben lässt.

Markenweite Standards in We.Inc mit dem Titel Was Ihre Kunden tun können, mit Schaltern für Veröffentlichen, eigene Domain, Code ansehen und weitere Funktionen

*Markenstandards. Schalten Sie den Code-Zugriff für alle aus und dann für den Kunden ein, dessen Entwickler ihn braucht.*

Fragen, die Sie jedem Anbieter zum Ausstieg stellen sollten

Stellen Sie sie uns und jedem anderen, den Sie evaluieren:

  1. Ist der Export derselbe Code, auf dem die Website läuft, oder eine konvertierte Kopie?
  2. Baut das exportierte Projekt ohne das Konto oder die Pakete des Anbieters?
  3. Welche Funktionen hängen nach dem Export von Diensten des Anbieters ab, und wie werden deren Daten exportiert?
  4. Können Sie eine Website, alle Websites oder beides exportieren? Wie lange dauert das für hundert?
  5. Wer in Ihrer Organisation kann exportieren, und lässt sich das pro Konto steuern?
  6. Können Sie den Export während der Test- oder Evaluierungsphase prüfen?

Bei We.Inc erfolgt der Export pro Website. Planen Sie bei einem großen Netzwerk die Zeit für den Export jeder Website ein, oder halten Sie die Websites laufend mit GitHub synchron, damit die Ausstiegskopie bereits existiert.

Wo andere Plattformen besser passen

Brauchen Sie ein klassisches CMS, in dem Nicht-Entwickler Tausende Inhaltseinträge über ein strukturiertes Backoffice verwalten, passt ein Headless- oder Enterprise-CMS besser als ein exportiertes React-Projekt. Werden Ihre Kunden nie einen Entwickler haben und nie wechseln, zählt der Export weniger als der Bearbeitungskomfort; sehen Sie sich stattdessen den visuellen Editor an.

Demo buchen und wir führen die obige Ausstiegsübung im Gespräch mit Ihnen durch.

Machen Sie die Ausstiegsübung im Demo-Gespräch

Buche eine 30-minütige Demo. Wir zeigen dir den Baukasten unter deiner Marke, sehen uns an, wie viele Kunden-Websites du betreiben willst, und nennen dir deinen genauen Preis.

Demo buchen

Lieber erst die ganze Tour? Den White-Label-Website-Baukasten ansehen

Fragen, die Käufer stellen

Kann ich den Code einer Kundenwebsite herunterladen?

Ja. Der Code-Bereich hat eine Schaltfläche Herunterladen, die ein ZIP des Projekts erzeugt. Reine Builder-Dateien werden entfernt, und das Projekt baut mit npm install und npm run build.

Welches Framework hat der exportierte Code?

React mit TypeScript, Tailwind CSS und Vite.

Funktioniert der GitHub-Sync in beide Richtungen?

Ja. Push sendet die Dateien des Builders an GitHub, Pull holt in GitHub gemachte Änderungen zurück. Sync ist auf den Projektinhaber und höhere Tarife beschränkt, serverseitig durchgesetzt.

Funktionieren Formulare, Shop und Logins nach dem Export weiter?

Nicht von allein. Diese Funktionen laufen über Dienste, die mit We.Inc verbunden sind. Der Code kommt mit Ihnen; die Dienste und ihre Daten nicht. Planen Sie also Ersatz und exportieren Sie Daten separat.

Kann ich den Code vor Kunden verbergen?

Ja. „Code ansehen“ ist ein Schalter pro Kunde mit einem markenweiten Standard.

Weiterlesen

Verwandt: White-Label-Website-Baukasten mit KI

Produkt

Für wen

Funktionen

Ressourcen

Unternehmen

Sitemap