One codebase, two brands, four skins. A design system built to run on a self-sustaining team.
E.ON Drive needed to sell charging across its own brand and a major automotive partner, in light and dark, across countries. We built one React-and-tokens system that did all of it, lean enough for a self-sustaining team of three to run.
The problem
Many brands, many countries, one small team
E.ON Drive sells EV charging across an ecosystem of products. Some under its own brand, some co-branded with automotive partners, on web and in an app, across multiple countries. Every brand wanted its own look. Every market had its own needs. The usual answer is more codebases, more people, more drift. E.ON Drive needed the opposite: a system a small team could keep running on its own, without any of that.
Separate front-ends per brand and market: duplicated work, and they drift apart over time.
My role
What I owned
I led the design-systems work as freelance Design Lead. I set the architecture, built the token model that let one codebase wear different brands, and worked alongside two developers to turn it into real, shipping React components. I also stood up how the system was run day to day, so a tiny team could keep moving without tripping over each other.
The effort was front-loaded on purpose. Heavier up front to get the architecture and tokens right, so that once it was ready for primetime the system scaled down to a barebones team of three to run and extend.
The approach
Unbranded by default, branded on demand
The core idea is simple: build the system unbranded. Components know nothing about E.ON or any partner. They just know structure, behaviour and accessibility. Brand lives entirely in design tokens. Swap the token set and the same component renders as E.ON or as the partner, in light or dark, without touching the component itself.
We wired the tokens straight into custom React, so a change a designer made in Figma flowed to real coded components instead of becoming a developer ticket. A colour fix that used to mean days or weeks of re-implementation became a same-day change. The system did the repetitive work; the three of us did the thinking.
A design system is a product that serves other products. Get the foundation right and the team stops reinventing the wheel and starts shipping.
One change in Figma flows through tokens into the components, then out to every brand and mode. Live across the Nordics.
The outcome
Live across the Nordics, and runnable by the team that stayed
The web experience went live multi-brand across the Nordics: E.ON Drive and a German automotive brand, light and dark, fully responsive, all from one codebase maintained by three people. A new brand was a new set of tokens, not a new project. A visual change reached live code in hours.
We designed and built the companion app too. It worked, and then the wider programme was cut before it shipped. The web system stayed live, and the team kept running and extending it without me. That was the point: build the foundation right, hand it over, and let a small team carry it.
Questions
What does "unbranded by default" mean?
The components carry no brand, only structure, behaviour and accessibility. All brand lives in design tokens. One component can render any brand by swapping the token set, so you maintain one thing instead of one per brand.
How does a design change reach live code without a developer rebuilding it?
Design tokens are wired directly into the React components. When a designer changes a token, the coded component updates from the same source of truth, with no hand re-implementation, so a change lands in hours instead of days.
Can three people really run a multi-brand design system?
Yes, if the architecture does the heavy lifting. With an unbranded component layer and tokenised brands, adding a brand or a mode is configuration, not new code, which is how a team of three kept two brands live in light and dark across the Nordics.
