We have consciously moved away from a strongly opinionated component library and now rely on headless components as the strategic foundation of our UI layer. This decision was not a pure styling refactoring, but an architectural decision that will enable more control, better scalability and greater independence in the long term.

The central idea behind headless components is the separation of behavior and presentation. While classic UI libraries often provide logic and visual implementation together, headless components focus exclusively on the functional level.

A headless component therefore provides the behavior of a UI component - such as state, interactions or accessibility mechanisms - but does not make any visual decisions. For example, it provides logic, ARIA handling, keyboard navigation and state management, but dispenses with fixed markup structures or styling.

The result: we are responsible for the entire visual design. The UI does not belong to a library, but to the product itself.

Our decision to use headless components is based on several structural considerations.

Control over our design system
With classic UI libraries, there is often a long-term tension: design wants individuality, product teams need speed and engineering struggles with overrides.
Headless Components solve this problem. As they have no visual opinion, we can completely define our design system ourselves, from design tokens and UI primitives through to the visual language of the product. Styling thus emerges directly from the design system and not in resistance to a library.

Reduction of structural dependencies
Opinionated component libraries come with their own abstractions, patterns and release cycles, including possible breaking changes
Headless components significantly reduce this dependency. We control the rendering layer, the styling layer and the API of our UI components ourselves and this reduces the migration risk in the long term.

Scalability in the front-end team
As the team grows, UI consistency becomes an organizational challenge. Headless primitives enable a clear layer structure in the UI system, such as primitives, composed components and feature components
Interaction logic can be reused, accessibility standards remain consistent and responsibilities are more clearly defined.

Accessibility as part of the architecture
Many UI libraries already provide integrated accessibility, but are often used as a black box
With headless components, we consciously deal with ARIA patterns and keyboard flows and integrate accessibility directly into our design system. Accessibility thus becomes part of the architecture and is not just a feature of a library.

Performance control
Opinionated libraries often come with generic abstractions and unused styles. Headless components, on the other hand, allow a minimalist markup structure and precise control over render paths.

This makes performance predictable instead of random.

This approach is not without effort. Headless components initially mean more architecture work, greater design system discipline and separate documentation. The effort must increase in the short term so that the structural complexity of the system can be reduced in the long term.

For us, headless components are not a styling tool or a trend, but an architectural principle in the UI layer. They create a clear separation of behavior and presentation, enable ownership via the UI API and reduce dependency on third-party libraries.