From the outside, this new website probably does not look dramatically bigger than the last one.

From the inside, it is by far the most ambitious rebuild we have done.

That gap between what is visible and what changed underneath is exactly why we wanted to write this.

Over the years, our website evolved in stages, and each version reflected what we needed at that moment.

The short history

Our first website was built with one goal: get online.

v1 was a one-day build. Single page, German only, fast to launch, enough to exist.

v2 took around a month. We spent more time on assets, moved to a multi-page setup, and built it in Webflow. It was still German only, but it felt much closer to the studio we wanted to present, more polished, more intentional, more complete.

This new phase took much longer than both of those versions. Not because it is massively bigger on the surface, but because underneath it became a very different kind of project.

Internally we have been calling it v2.5, not because anyone outside our team needs to care about version numbers, but because this release sits somewhere between the older public-facing website and a more unified long-term direction we are building toward.

Why this version took so long

This rebuild happened slowly in the background, usually whenever we had space between client work, internal products, and experiments.

Once you move from a visual website workflow into a custom-coded system, lead times naturally increase. More decisions, more edge cases, more architecture, and a lot more opportunities to rethink things halfway through. In our case, we tore the website down internally more than twice while experimenting.

For such a small public website, the amount of custom library code behind it is honestly a bit absurd. But that is also the point. This version was not built for the shortest path to launch. It was built as a stronger long-term base.

Webflow was not the problem

This is important to say clearly: this is not a "Webflow bad, code good" story.

We still think Webflow is a fantastic tool. For experienced designers and developers, it is one of the strongest environments for fast visual iteration, CMS-driven marketing websites, and highly polished animation-heavy pages. The same goes for tools like Framer, Wix, or headless CMS setups like Payload, Dato, or Strapi. All of them make a lot of sense when a team needs editors, PMs, marketers, or non-technical stakeholders to manage content through a usable interface. That is a real requirement on many projects.

Our website is no longer just a place to present services and case studies, it is becoming a surface where we can experiment. Only a small number of developers will touch the content and system here, so maintaining a CMS layer would mostly add overhead. It is often faster and cleaner for us to work directly in code, which is why an MDX-based setup made sense: it keeps content close to components, removes editor overhead we do not need, and gives us more flexibility for the kind of iteration we want to do now.

That does not mean clients should copy this setup. A big part of our work is helping clients choose the right level of complexity for their actual needs. The answer should come from the use case, not from ideology.

Why Next.js was the right call

Once we knew what this website needed to become, Next.js felt like the obvious fit.

We wanted a React-based environment for handling more complex UI states and interactions, SSR where it actually helps, middleware and proxy behavior without awkward workarounds, and a backend-friendly architecture that could support Supabase-powered flows and Resend-based messaging cleanly. We also wanted one system that could hold polished marketing pages, experimental interfaces, and more technical demos without us having to rethink the stack again later.

The new architecture already has a lot in place: bilingual structure for German and English, accessibility foundations, multiple theme layers, a Supabase-backed backend, Resend integration for email flows, and custom middleware and routing patterns.

What it also has room for is what matters more, custom AI helpers, programmable content workflows, machine-readable content structures, internal tools, MCP-style experiments, and user-facing demos we can publish here for clients and others to explore with us. The website is becoming a programmable content surface, which gives us much more freedom to experiment with how content is authored, enriched, structured, transformed, and presented, both for people and for machines.

What this means beyond our own website

There is also a client-facing reason we wanted to build this way.

Our own website is becoming a place where we test systems, workflows, and interaction ideas before or alongside applying similar thinking in client work. Being able to design, build, and evaluate these systems ourselves makes us better at choosing the right level of complexity for the people we work with.

Not every client needs a custom-coded architecture. Not every project should avoid a CMS. And not every website needs this much technical depth. But having built it ourselves means we understand the tradeoffs in practice, not just in theory.

More foundation than finish

This release matters, but it is still a transition point.

A lot of pages are still gated and unpublished. A lot of the visible design ideas we want to test on subpages are still ahead of us. Even some parts of the current shell still belong more to the older generation of the website than to the next one, and that is fine.

Rather than disappearing for another long cycle and trying to emerge with one finished launch, we want to build more of this in public, piece by piece. The next visible slice will likely be the redesign of navigation and footer, followed by more page releases, more experiments, and more writing and videos around the systems behind them.

So if there is a simple way to describe this release: this is not the final version, it is the foundation.