Von Wix zur eigenen Plattform — Warum wir unsere Website neu gebaut haben

Dieser Beitrag ist eine Retrospektive. Kein Verkaufspitch, kein „Wix ist schlecht“-Rant. Wix hat uns gute Dienste geleistet, als wir schnell eine Webpräsenz brauchten. Aber irgendwann passte die Lösung nicht mehr zum Problem. Und dann haben wir die Website neu gebaut. Das hier ist die Geschichte, was dabei gut lief, was schiefging und was wir daraus gelernt haben.

Warum Wix am Anfang die richtige Wahl war

Als Just Tech Solutions GmbH 2022 gegründet wurde, brauchten wir eine Website. Schnell. Wir waren ein kleines Team, das seine Zeit in Kundenprojekte stecken wollte, nicht in die eigene Homepage. Wix war die offensichtliche Wahl: Drag-and-Drop-Editor, Hosting inklusive, SSL-Zertifikat automatisch, Domain-Verwaltung integriert. Innerhalb von zwei Tagen stand die Seite. Das war genau das, was wir brauchten.

Und für eine Weile funktionierte es gut. Die Seite war online, sie sah ordentlich aus, und wir konnten uns auf das konzentrieren, wofür wir gegründet worden waren: Technologie für DAOs bauen.

Die Probleme, die sich aufstauten

Das Umdenken begann nicht mit einem einzelnen Ereignis, sondern mit einer sich häufenden Liste von Ärgernissen. Lassen Sie mich sie in der Reihenfolge auflisten, in der sie kritisch wurden.

Problem 1: Performance. Wir hatten eine einfache Unternehmensseite mit fünf Unterseiten, keinen Shop, kein CMS, keine dynamischen Inhalte. Trotzdem lud Wix beim ersten Besuch über 3 MB an JavaScript, CSS und Schriften. Der Lighthouse Performance Score lag bei 42 von 100. Für eine Firma, die professionelle Webentwicklung anbietet, war das peinlich. Wir sagten unseren Kunden, sie sollten auf Performance achten, während unsere eigene Seite langsamer lud als manches Web-Game.

Problem 2: Vendor Lock-in. Als wir die Seite inhaltlich umstrukturieren wollten, merkten wir, wie tief wir in Wix steckten. Es gab keinen Export-Button. Kein „Hier ist Ihr HTML, viel Spaß“. Alles — Texte, Bilder, Seitenstruktur — existierte nur innerhalb des Wix-Editors. Selbst ein einfacher Textexport erforderte manuelles Copy-Paste. Für ein Unternehmen, das täglich über Dezentralisierung und Souveränität spricht, war es schon ironisch, dass unsere eigene Website in einem proprietären System eingesperrt war.

Problem 3: DSGVO-Compliance. Das war der Punkt, der uns am meisten beunruhigte. Wix lädt standardmäßig Tracking-Skripte, Google Fonts von externen Servern und verschiedene Third-Party-Ressourcen. Einiges davon lässt sich abschalten, aber nicht alles. Die Datenschutz-Grundverordnung verlangt, dass personenbezogene Daten nur mit Einwilligung an Dritte übertragen werden. Bei Wix hatten wir nie die vollständige Kontrolle darüber, welche Daten wohin flossen. Also brauchten wir einen Cookie-Banner, der um Einwilligung bat — für Datenübertragungen, die wir eigentlich gar nicht wollten.

Problem 4: HTML-Qualität. Ein Blick in den Quellcode einer Wix-Seite ist lehrreich — im negativen Sinne. Verschachtelte Divs ohne semantische Bedeutung, Inline-Styles in Dutzenden von Ebenen, auto-generierte Klassennamen wie _2sDMM und _1Q9if. Für Barrierefreiheit, SEO und Wartbarkeit ist das ein Albtraum. Screenreader tun sich schwer mit Markup, das keine semantische Struktur hat. Suchmaschinen können die Seitenhierarchie kaum nachvollziehen. Und wenn ein Entwickler den Quellcode liest, sieht er nichts, was ihm weiterhilft.

Die Entscheidung

Im November 2025 haben wir die Entscheidung getroffen: Wir bauen die Seite selbst. Die Anforderungen waren klar:

Erstens: Maximale Performance bei minimalem Overhead. Die Seite hat statische Inhalte — sie braucht kein React, kein Vue, kein Framework, das zur Laufzeit JavaScript interpretiert. Zweitens: Vollständige Kontrolle über jedes Byte, das an den Browser gesendet wird. Keine versteckten Tracking-Skripte, keine externen Font-Server, keine Third-Party-Cookies. Drittens: Sauberes, semantisches HTML, das barrierefrei, wartbar und versionierbar ist. Viertens: DSGVO-Compliance ohne Cookie-Banner, weil es schlicht nichts gibt, wofür eine Einwilligung nötig wäre.

Der Tech-Stack

Nach einer Evaluationsphase haben wir uns für folgenden Stack entschieden:

Vite als Build-Tool. Vite bietet schnelles Hot Module Replacement während der Entwicklung und einen optimierten Production-Build mit Tree Shaking, Code Splitting und Asset Optimization. Für eine statische Seite ist Vite ideal, weil es sich auf das Wesentliche beschränkt, ohne die Komplexität eines Full-Stack-Frameworks mitzubringen.

TypeScript für die wenigen interaktiven Elemente. Die Website braucht kaum JavaScript — das mobile Navigationsmenü, ein Scroll-Verhalten im Header, vielleicht ein Kontaktformular in der Zukunft. Aber selbst für wenig Code lohnt sich TypeScript: Die Typsicherheit verhindert Fehler, die IDE-Unterstützung beschleunigt die Entwicklung, und der Code dokumentiert sich teilweise selbst.

Tailwind CSS für das Styling. Tailwind war eine bewusste Entscheidung. Die Utility-First-Philosophie bedeutet, dass nur die CSS-Klassen im Production-Build landen, die tatsächlich verwendet werden. Kein ungenutzter CSS-Ballast, kein Überschreiben von Framework-Defaults. Und die Design-Token — Farben, Abstände, Schriftgrößen — erzwingen Konsistenz, ohne dass wir ein eigenes Design-System bauen mussten.

Statisches HTML für die Seiten selbst. Keine Template-Engine, kein Static-Site-Generator, kein CMS. Jede Seite ist eine handgeschriebene HTML-Datei. Das klingt altmodisch, und das ist es auch. Aber für eine Seite mit weniger als zwanzig Unterseiten ist es die einfachste Lösung mit der geringsten Komplexität. Wenn die Seite wächst, können wir immer noch einen Generator einführen. Aber wir fügen Komplexität nur dann hinzu, wenn sie benötigt wird — nicht prophylaktisch.

Die Ergebnisse

Die Zahlen sprechen eine deutliche Sprache.

Gesamtgröße der deployten Seite: 444 KB. Das ist die komplette Website — HTML, CSS, JavaScript, Schriften, alles. Zum Vergleich: Die Wix-Version lud allein beim ersten Seitenaufruf der Startseite über 3 MB. Das ist eine Reduktion um den Faktor sieben.

Lighthouse Score: 100 in Performance, 100 in Accessibility, 100 in Best Practices, 100 in SEO. Nicht weil wir auf Lighthouse-Scores optimiert haben, sondern weil eine saubere, semantische Seite ohne Bloat diese Scores als Nebenprodukt liefert.

Externe Anfragen: Null. Die Seite lädt keine externen Schriften, keine Analytics-Skripte, keine Third-Party-Ressourcen. Alles wird vom eigenen Server ausgeliefert. Und deshalb brauchen wir keinen Cookie-Banner: Es gibt keine Cookies, die eine Einwilligung erfordern würden.

First Contentful Paint: Unter 0,5 Sekunden auf einer durchschnittlichen Mobilverbindung. Die Wix-Version lag bei über 2 Sekunden.

Was schwieriger war als erwartet

Ehrlichkeit gehört zu einer guten Retrospektive. Also hier ist, was uns mehr Zeit gekostet hat als geplant.

Zweisprachigkeit. Die Website gibt es auf Deutsch und Englisch. Bei Wix war das ein Feature — Knopf drücken, fertig. Ohne CMS mussten wir jede Seite doppelt pflegen. Die Hreflang-Tags, die kanonischen URLs, die Sprachumschalter — das ist alles kein Hexenwerk, aber es ist manuelle Arbeit, die sich bei jeder neuen Seite wiederholt. Rückblickend hätte ein minimaler Templating-Ansatz hier Zeit gespart.

Selbstgehostete Schriften. Google Fonts von externen Servern zu laden ist aus DSGVO-Sicht problematisch. Also haben wir die Schriften selbst gehostet. Das Subsetting — nur die Glyphen einzupacken, die wir tatsächlich brauchen — und die Optimierung der Font-Loading-Strategie hat überraschend viel Recherche und Testing erfordert. Das Ergebnis ist gut: Die Schriften laden schnell und ohne Layout-Shift. Aber der Weg dahin war aufwändiger als „Font herunterladen und einbinden“.

Content-Migration. Da Wix keinen strukturierten Export anbietet, haben wir jeden Text manuell kopiert, in sauberes HTML überführt und dabei gleichzeitig überarbeitet. Das war die richtige Entscheidung — der Content war ohnehin überarbeitungsbedürftig — aber es hat die Timeline um etwa eine Woche verschoben.

Was einfacher war als erwartet

Deployment. Die Seite wird über eine einfache CI/CD-Pipeline deployt: Push auf den Main-Branch, Build wird ausgelöst, statische Dateien werden auf den Server kopiert. Keine Container-Orchestrierung, kein Kubernetes, kein Serverless. Eine statische Seite braucht nichts von alldem. Der gesamte Deployment-Prozess dauert unter dreißig Sekunden.

Barrierefreiheit. Wir hatten befürchtet, dass die Accessibility-Anforderungen viel Zusatzarbeit verursachen würden. In der Praxis war das Gegenteil der Fall. Semantisches HTML — also <nav>, <main>, <article>, <header> anstelle von <div class="_2sDMM"> — ist bereits der größte Schritt Richtung Barrierefreiheit. ARIA-Labels an den richtigen Stellen, ein Skip-Link, ausreichende Farbkontraste — das ist Handwerk, nicht Raketenwissenschaft. Der Aufwand war minimal, das Ergebnis ein perfekter Accessibility-Score.

Wartbarkeit. Der gesamte Quellcode der Website liegt in einem Git-Repository. Jede Änderung ist nachvollziehbar, jede Version ist wiederherstellbar. Code-Reviews für Content-Änderungen klingen übertrieben, sind aber in der Praxis sehr wertvoll: Tippfehler, kaputte Links und inkonsistente Formulierungen fallen im Review auf, bevor sie live gehen.

Lessons Learned

Erstens: Starten Sie mit einem Baukasten, wenn Sie müssen. Wix, Squarespace, Webflow — diese Tools haben ihre Berechtigung. Wenn Sie eine Website in zwei Tagen brauchen und Ihr Kerngeschäft woanders liegt, ist ein Baukasten die richtige Wahl. Wir bereuen die Zeit auf Wix nicht.

Zweitens: Wissen Sie, wann der Baukasten nicht mehr reicht. Performance, Datenschutz, Kontrolle — wenn diese Punkte für Ihr Geschäft relevant werden, ist der Zeitpunkt zum Wechsel gekommen. Warten Sie nicht, bis es eine Krise gibt.

Drittens: Die einfachste Lösung ist oft die beste. Statisches HTML mit Tailwind und Vite ist keine aufregende Architektur. Es gibt keinen Vortrag, den Sie auf einer Konferenz damit halten können. Aber es funktioniert, es ist schnell, es ist wartbar, und es löst das Problem. Technologie sollte dem Zweck dienen, nicht dem Lebenslauf.

Viertens: DSGVO-Compliance ist einfacher ohne Drittanbieter. Der einfachste Weg, einen Cookie-Banner loszuwerden, ist, keine Cookies zu setzen, die eine Einwilligung erfordern. Und der einfachste Weg dorthin ist, keine Drittanbieter-Skripte zu laden. Das ist kein technischer Trick — es ist eine Designentscheidung.

Und fünftens: Messen Sie das Ergebnis. 444 KB statt 3+ MB. Lighthouse 100 statt 42. Null externe Anfragen statt Dutzenden. Kein Cookie-Banner statt eines, der Besucher nervt. Diese Zahlen sind kein Selbstzweck, aber sie sind ein guter Indikator dafür, dass die Entscheidung richtig war.

Die Website, auf der Sie diesen Text gerade lesen, ist das Ergebnis. Sie ist nicht perfekt — die manuelle Zweisprachigkeit ist ein Kompromiss, den wir irgendwann auflösen werden. Aber sie ist schnell, sie ist sauber, sie ist unsere, und sie tut genau das, was sie soll. Manchmal ist das genug.