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
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.
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.

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

*Der Quelltext des Hero-Bereichs. Text, den Kunden visuell bearbeiten, wird in diese Dateien zurückgeschrieben.*
| Weg | Was Sie bekommen | Wer ihn nutzen kann | Geeignet für |
|---|---|---|---|
| ZIP herunterladen | Das ganze Projekt, ohne reine Builder-Dateien | Jeder mit der Berechtigung „Code ansehen“ für diese Website | Übergabe an den Entwickler eines Kunden, Archivierung bei Vertragsende |
| Nach GitHub exportieren | Ein neues Repository mit dem Projekt, standardmäßig privat | Projektinhaber, mit verbundener GitHub-App oder Personal Access Token | Teams, die eine Versionshistorie außerhalb von We.Inc möchten |
| Zwei-Wege-GitHub-Sync | Aus dem Builder pushen, in GitHub gemachte Änderungen zurückholen | Projektinhaber, nur höhere Tarife (serverseitig geprüft) | Entwickler, die zwischen KI- und visuellen Bearbeitungen in eigenen Tools arbeiten |

*Der Export-Dialog. Ein Repository-Name, eine Option für ein privates Repository und daneben ein ZIP-Tab.*
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.
Seien Sie Ihren Kunden gegenüber ehrlich mit dieser Liste. Genau hier gehen Migrationen schief.
Machen Sie das während der Evaluierung, nicht am Vertragsende.
Wenn ein Schritt fehlschlägt, sprechen Sie es im Demo-Gespräch an. Wir wissen es lieber.
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.

*Markenstandards. Schalten Sie den Code-Zugriff für alle aus und dann für den Kunden ein, dessen Entwickler ihn braucht.*
Stellen Sie sie uns und jedem anderen, den Sie evaluieren:
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.
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.
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.
Lieber erst die ganze Tour? Den White-Label-Website-Baukasten ansehen
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.
React mit TypeScript, Tailwind CSS und Vite.
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.
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.
Ja. „Code ansehen“ ist ein Schalter pro Kunde mit einem markenweiten Standard.