About us

The spark

The hope was that AI would break down silos. Now, alongside Figma and code, we have more: the prototype silos.

We heard sentences like this more and more often over the past few years. Because the arrival of AI accelerated a lot — but it did not simplify design processes.

One example: prototyping is exploding. In companies, more and more functional prototypes are being created — well beyond the design team, across every department. And because so much convincing work appears so quickly, expectations around delivery grow. “That's basically done already.” So more and more tasks land on the design team — which becomes even more of a bottleneck as a result. Because now there are three design truths drifting apart: Figma, code, and assorted prototypes.

AI cannot solve this development — only people can improve processes. The answer to the sprawl is not a ban on vibe coding, but a shared, versioned design foundation: a design system as a resource.

Precisely because departments can now prototype so much themselves, something is needed that reconnects it all — not another tool, but a common foundation. That was exactly the spark for Componiq.

The core team

Systems thinking meets problem thinking.

Design System Engineering

Sascha Rinaldi

Knows corporate Scrum teams from the inside — and the recurring friction points of embedded design teams. Separate tool worlds create separate language cultures, and it is exactly there, at the seam between design and code, that handover processes break.

The insight: a better design system is rarely the actual problem. Most of the time it fails on the coordination processes between departments, design, and engineering. Whether a system holds up is decided not on the surface, but in the structure.

Product / CX

Christian Wiener

Asks the uncomfortable question first: which problem is even worth solving? The knowledge comes from dozens of enterprise projects and three of his own startups — what makes complex product development succeed, and where it fails.

The approach: stay in contact with real users and keep validating. That way, design-system decisions are made where they become strategic: between user needs, organization, and technology.

The two levels of transformation

A design system used to be the design team’s concern. Now it is the whole organization’s concern.

On one level it is about craft: exactly how tokens are structured, which architecture can carry the load, how components, themes, and distribution mesh together. This is precise, technical work — and without it every design system stays a promise without substance.

But a design system that is only technically clean still fails. It then sits well-maintained in the repository while the organization around it keeps working as before — with the same coordination paths, the same silos, the same breaks between design and code.

Because on the other level it is about change: how teams make decisions, how knowledge is shared, who contributes what and when. A design system changes how an organization works — whether it wants to or not. It is always a digital transformation process too.

Whoever sees only the technology builds a system no one uses. Whoever sees only the transformation talks about processes without anything load-bearing ever emerging. The two belong together — and that is exactly the seam we work on. Not one before the other, but both as the same project.

Let's talk about
Transformation.

Get in touch