Von außen wirkt diese neue Website vermutlich nicht dramatisch größer als die vorherige.

Von innen ist sie bei weitem der ambitionierteste Relaunch, den wir bisher gemacht haben.

Genau diese Lücke zwischen dem, was sichtbar ist, und dem, was sich darunter verändert hat, wollen wir hier erklären.

Im Laufe der Jahre hat sich unsere Website in Etappen weiterentwickelt, und jede Version spiegelte wider, was wir in dem Moment brauchten.

Die kurze Geschichte

Unsere erste Website hatte ein Ziel: online gehen.

v1 war ein One-Day-Build. Eine Seite, nur Deutsch, schnell live, genug, um existieren zu können.

v2 hat etwa einen Monat gedauert. Wir haben mehr in Assets investiert, sind auf mehrere Seiten gewechselt und haben in Webflow gebaut. Weiterhin nur Deutsch, aber deutlich näher am Studio, das wir zeigen wollten: polierter, bewusster, runder.

Diese neue Phase hat deutlich länger gedauert als beide Versionen zuvor. Nicht, weil die Oberfläche massiv gewachsen ist, sondern weil das Projekt darunter eine andere Art von Projekt geworden ist.

Intern nennen wir es v2.5, nicht, weil Menschen außerhalb unseres Teams Versionen mitverfolgen müssten, sondern weil dieser Stand zwischen der älteren öffentlichen Website und einer langfristigeren, einheitlicheren Richtung liegt, auf die wir hinarbeiten.

Warum diese Version so lange gedauert hat

Der Relaunch ist langsam im Hintergrund gewachsen, immer dann, wenn zwischen Kundenarbeit, internen Produkten und Experimenten Luft war.

Sobald man von einem visuellen Website-Workflow zu einem maßgeschneiderten, codierten System wechselt, steigen die Vorlaufzeiten natürlich. Mehr Entscheidungen, mehr Edge Cases, mehr Architektur, und deutlich mehr Chancen, mitten drin neu zu denken. Wir haben die Website intern mehr als zweimal neu aufgesetzt, während wir experimentiert haben.

Für eine so kleine öffentliche Website ist die Menge an eigener Library-Code-Basis fast schon übertrieben. Genau darum geht es aber auch. Diese Version war nicht für den kürzesten Weg bis zum Launch gedacht, sondern als stärkere langfristige Basis.

Webflow war nicht das Problem

Das wollen wir klar sagen: Das hier ist keine „Webflow schlecht, Code gut“-Story.

Webflow finden wir nach wie vor ein großartiges Tool. Für erfahrene Designer und Entwickler ist es eines der stärksten Umfelder für schnelle visuelle Iteration, CMS-getriebene Marketing-Websites und stark animierte Seiten. Das gilt genauso für Tools wie Framer, Wix oder Headless-Setups wie Payload, Dato oder Strapi. Sie sind allesamt sinnvoll, sobald Redaktion, PMs, Marketing oder andere Stakeholder Inhalte über eine nutzbare Oberfläche pflegen sollen. Das ist auf vielen Projekten eine echte Anforderung.

Unsere Website ist nicht mehr nur eine Präsentationsfläche für Services und Case Studies, sie wird zu einer Oberfläche, auf der wir experimentieren können. Nur wenige Entwickler werden hier Inhalte und System anfassen. Eine CMS-Schicht wäre für uns vor allem Mehraufwand. Für uns ist Arbeit direkt im Code oft schneller und klarer, deshalb hat ein MDX-basierter Ansatz Sinn ergeben: Inhalte bleiben nah an Komponenten, Editor-Overhead entfällt, und wir gewinnen Flexibilität für die Iteration, die wir jetzt wollen.

Das heißt nicht, dass Kund:innen dieses Setup kopieren sollten. Ein großer Teil unserer Arbeit ist, gemeinsam die passende Komplexität für den jeweiligen Bedarf zu wählen. Die Antwort soll vom Use Case kommen, nicht von Ideologie.

Warum Next.js für uns passte

Sobald klar war, wohin diese Website soll, war Next.js für uns die naheliegende Wahl.

Wir wollten React für komplexere UI-Zustände und Interaktionen, SSR dort, wo es wirklich hilft, Middleware und Proxy-Verhalten ohne verkrampfte Workarounds und eine Architektur, die Supabase-Flows und Resend sauber trägt. Dazu ein System, das gepflegte Marketingseiten, experimentelle Oberflächen und technischere Demos zusammenhalten kann, ohne den Stack später neu erfinden zu müssen.

In der neuen Architektur steckt schon viel: zweisprachige Struktur für Deutsch und Englisch, Grundlagen für Barrierefreiheit, mehrstufige Themes, ein Supabase-basiertes Backend, Resend für E-Mail-Flows sowie eigene Middleware- und Routing-Patterns.

Dazu kommt der Raum für das, was für uns noch wichtiger ist: eigene KI-Helfer, programmierbare Content-Workflows, maschinenlesbare Strukturen, interne Tools, MCP-artige Experimente und Demos, die wir hier veröffentlichen, um sie mit Kund:innen und anderen gemeinsam zu erkunden. Die Website wird zu einer programmierbaren Content-Oberfläche, mit deutlich mehr Freiheit, zu erproben, wie Inhalte entstehen, angereichert, strukturiert, transformiert und präsentiert werden: Für Menschen und Für Maschinen.

Was das über unsere eigene Website hinaus bedeutet

Es gibt auch einen für Kund:innen relevanten Grund für diesen Weg.

Unsere Website wird zu einem Ort, an dem wir Systeme, Workflows und Interaktionsideen testen, bevor wir ähnliche Denkweisen in der Kundenarbeit anwenden oder parallel dazu. Wenn wir diese Systeme selbst entwerfen, bauen und bewerten, werden wir besser darin, für die Menschen, mit denen wir arbeiten, die passende Komplexität zu wählen.

Nicht alle Kund:innen brauchen eine komplett codierte Architektur. Nicht jedes Projekt sollte auf ein CMS verzichten. Und nicht jede Website braucht so viel technische Tiefe. Weil wir es aber selbst gebaut haben, verstehen wir die Abwägungen in der Praxis, nicht nur in der Theorie.

Mehr Fundament als Finish

Dieser Release zählt, und er markiert dennoch einen Übergang.

Viele Seiten sind weiterhin geschützt oder unveröffentlicht. Viele sichtbare Designideen für Unterseiten liegen vor uns. Sogar Teile der aktuellen Hülle gehören noch stärker zur älteren Generation der Website als zur nächsten, und das ist in Ordnung.

Statt wieder monatelang abzutauchen und mit einem fertigen Launch aufzutauchen, wollen wir mehr davon öffentlich Stück für Stück ausbauen. Der nächste sichtbare Schritt wird vermutlich das Redesign von Navigation und Footer sein, gefolgt von weiteren Seiten, Experimenten sowie mehr Text und Video zu den Systemen dahinter.

Kurz gesagt, wenn wir diesen Release in einem Satz beschreiben sollen: Das ist nicht die finale Version, es ist das Fundament.