How it all started

In 2024, Delivery Hero had a design system called Armor.

It worked and was built to solve a very specific problem: Provide a unified experience for backoffice users. It supported roughly 35–40 products

Armor’s Limits

Armor wasn’t a bad system. It had simply reached the limits of what it was designed to do. It was originally built to solve Backoffice UI problems quickly, and that made sense at the time. But as Delivery Hero grew, those decisions started becoming constraints.

• No semantic versioning – Teams couldn’t safely move back to a previous version when something went wrong.
• No responsive experience – It wasn’t built for mobile-first designs and it’s architecture wasn’t designed to scale beyond the problems it was originally created to solve.
• Not multi-brand – The system couldn’t cater to products in different markets.
• Robust patterns – As new products emerged, even foundational needs such as robust form patterns were missing.
• Consolidation opportunity – Armor wasn’t the only system we had to think about. There was two other systems also needed to be consolidated. Vendor was already using a Material UI-based system and supporting products across all nine Delivery Hero brands. So the challenge was no longer simply about making Armor better.

We had an opportunity to rethink the foundation itself.

How do we create one design system that can serve the organisation we are becoming?

---

Choice

My Engineering Manager and I looked at two options: build a new version of Armor or start a new design system with a new foundation. The estimated effort was roughly the same.

That made the decision clearer. If we were going to invest the same amount of time, I didn’t want to rebuild the same limitations into another version of Armor. I proposed that we start fresh.

That became Cape.

I owned the product direction from vision and roadmap to OKRs, prioritisation, adoption and stakeholder alignment. My Engineering Manager helped validate the technical feasibility, but the decision to move forward with Cape was mine.

---

Foundation

Before Cape could credibly replace the legacy systems or consolidate many into one, I first defined what the new foundation needed to support. That meant web and mobile, a broader component foundation, RTL, theming, and accessibility.

These became our acceptance criteria not just for the initial build, but for every roadmap decision that followed. If a capability didn’t move us closer to that foundation, we had to question whether it belonged on the roadmap.

I also defined our three-tier architecture Core (central, owned by Cape team), Expansion (product-group-specific, built on Core), and Local (team-specific, not shared). This gave teams a way to move without forking the system.

Migration

The harder part was getting people to use it. Teams already had roadmaps, features to ship, and deadlines to meet. And just a year earlier, some of those same teams had been asked to adopt Armor.

I didn’t want Cape to become another migration project competing for their capacity. So instead of asking teams to stop and migrate, we changed the way adoption worked.

Instead, we created the Armor Theme inside Cape. Teams could start using Cape while keeping the visual language they already had, so they didn’t have to turn migration into a separate project.

The transition became:

Armor → [ Cape + Armor Theme ] for New features → and eventually switch to Cape Theme

Rather than: Stop → Migrate everything → Redesign → Start again

This was a deliberate choice. I wanted to make the better foundation the easier choice.

Adoption

During the adoption, I met with Product Managers, Engineering Managers and Design Managers across the organisation to understand what they were building and where Cape could actually help. I didn’t start the conversation with “You need to migrate.” I started with a much simpler question: “What are you trying to build?”

My rule was simple: without a user, we don’t build.

I treated Cape like any other product. It had users, problems to solve and limited capacity. When a team asked for something, I looked at the strength of the need, how important it was to their product, whether other teams had the same problem, and whether the complexity justified design-system expertise.

Sometimes the answer was no.

For example, we were asked to build a template that the product team could easily compose themselves. We decided not to build it.

A design system shouldn’t become a warehouse for everything teams don’t want to build.

But Side navigation component was different. Through regular conversations with PMs and Design Managers, I knew what was coming through their roadmaps and OKRs. When more than three teams independently requested Side Navigation, it was a clear signal that this wasn’t just one team’s problem.

We also looked at the complexity. It was the kind of problem where design-system expertise could add real value. We decided to build it as a pattern rather than a component, because there was no logic that needed to live inside the system.

Reuse doesn’t automatically mean component.

The same thinking applied to larger problems. One product team needed a complex table with resizing and sorting. Their initial plan was to use a third-party library and build the experience themselves.

Instead of immediately building it for them, I asked:

Who else needs this?

When we saw that the need could extend beyond one team, it became a CAPE opportunity. Rather than every product solving the same problem independently, we could absorb the complexity once and make it available to others.

A product need could become a system opportunity when there was enough evidence behind it.

---

Trade-off

Not every product request could be supported immediately. There were situations where a team had an urgent deadline, but Cape couldn’t safely design, test and release the capability within their timeline.

In those cases, I was comfortable telling them to wait and explaining why.

A design system needs time to get things right. A decision made in one product affects that product only but in a design system can affect many products.

The system is slow for a reason.

For a long time, we deliberately kept adoption organic. In a large organisation with many products and dependencies, setting a hard migration deadline sounds simple but doesn’t always work in reality. We tried stronger migration targets and learned that they were not the right mechanism for us.

So we focused on making Cape useful enough that teams wanted to use it.

But eventually, there was another problem: keeping two systems alive was itself costly.

That changed the decision.

In September 2025, Armor was formally moved into legacy/deprecated status. We were no longer investing in two competing foundations. Cape was the direction forward, while teams were given the space to manage the transition alongside their product priorities.

---

Impact

We didn’t rely only on conversations to understand adoption. We built a monthly crawler that scans our GitHub repositories and identifies which design systems projects are using.

By May 2026, the crawler had scanned React projects and the results showed 100+ projects using Cape and 150+ using Armor.

The numbers also showed how much the role of Cape had changed. It was no longer just a Backoffice system. It had expanded into Vendor, Helpcenter, Ops Portal and Android products, while becoming the current-standard internal system.

Migration isn’t a switch. It is a landscape.

The work had moved from building a new system to changing the system landscape of the organisation.

What started as a foundation for the next generation of products has grown into a system supporting 45+ components, 9 brands and 100+ products across multiple platforms.

But the scale isn’t only about how many components we have. The real value comes from the work that product teams no longer need to repeat. Our modelling estimated around €30K in monthly delivery cost avoided through Cape reuse compared with teams independently building equivalent capabilities with open-source systems.

For me, that’s the leverage of a design system:

Build once. Use many times.

And let product teams spend their capacity on problems that actually differentiate their products.

---

Adoption is a product problem

If adopting a design system is painful, teams will find ways around it. The best migration strategy isn’t always the strongest mandate. Sometimes it’s simply removing the reason people don’t want to migrate. For us, that meant the Armor Theme.

A design system should have users before it has features

I don’t believe in building components because they might be useful one day. I want evidence of a real problem, a team that needs it, and ideally a problem that can be solved once and reused many times.

Frameworks shouldn’t replace judgement

Large organisations are complicated. There is no single migration framework that works everywhere. Sometimes you push. Sometimes you wait. Sometimes you say no.

The job is to understand the complexity of the situation and make the right decision without compromising quality.