Taking control of an inherited component library
I inherited a cross-project component library I hadn’t designed, with no budget and no clear scope. As frontend tech lead on a multi-brand automotive account, I turned it into a token-driven design system themed across seven brands, trading open-ended flexibility for controlled choices.
- Role
- Frontend tech lead, supporting 3 squads (~15 people)
- Client
- Large multi-brand automotive client, through Nurun
- Stack
- StencilJS web components, Vue.js, AngularJS, Java with FreeMarker, Figma API
- Scope
- Feature architecture, frontend stack, team coaching, design system
~30components
~500primitive and semantic tokens
7×2brands, each in light and dark
01Context
Another lead had started a component library meant to be shared across Nurun’s client projects. The goal was to make it highly customizable, so projects with very different design directions could all build on the same foundation.
Some foundational choices were already made when I joined. The library was built as web components with StencilJS, so the same components could be shared across different technologies and projects.
My initial mandate was to help put that library in place. When the colleague who started it left, it was handed to me, along with its vision, setup and requirements, none of which I had been involved in.
The library was only part of my job. As the frontend tech lead on the automotive client account, I also defined the technical approach for every new feature, supported three squads of about 15 people, coached the team, and improved the project’s frontend stack. The design system work had to fit alongside all of that.
02Challenges
- 01
A mixed legacy stack
The client platform ran on Java with FreeMarker server templating and legacy AngularJS, with Vue.js chosen to gradually replace it. Components had to work across several stacks at once.
- 02
No budget, no scope, little pull
The initiative had no funding and no clear definition, and other teams’ features, budgets and deadlines always came first.
- 03
Code before design
The library was built before any design system existed: one prop for nearly every visual detail, where a design system defines a few clean variants.
- 04
Too much freedom
CSS strings injected through props, and instead of tokens, an exhaustive list of CSS variables, like one for every padding from 0 to 100.
03Token architecture
With the project’s UI lead and another designer, I defined a token foundation designed to scale and to enable theming, in three layers:
Raw values
Primitive tokens
--stla-font-size-16--stla-color-blue-50
The raw values, such as colors and spacing.
Themes swap here
Semantic tokens
--stla-background-color-brand-default--stla-text-size-body-lg
Give those values meaning and intent. This is the layer each brand theme replaces.
Built on tokens
Utility classes
.stla-lg-heading-1.stla-global-form-label
Consistent styling without one-off values.
Replacing the old list of CSS variables would have meant more refactoring than the budget allowed, so the new tokens were added as a separate system, living in parallel with the old variables. Theming was rolled out to every brand: new development used it fully, while existing styles were only partly migrated.
04Approach
With no budget and no shared roadmap, I used my own client project as the vehicle for moving the library forward.
Work through a client project
I developed the library inside the automotive client project. Each improvement was driven by an actual client need, which justified the time and tested the library under real conditions.
Coaching the team. Most of the team hadn’t worked with a component library before. The hardest shift was mindset: building components in isolation, free of any application context, is very different from developing features inside a full application.
Make change safe
Before touching the design, I set up automated versioning and changelogs. Teams could adopt new versions incrementally, so the library could evolve without breaking the projects that depended on it.
Build a real token foundation
The project’s UI lead wanted to start a design system, and I partnered closely with her. Over many working sessions with her and another designer, we defined the three-layer token foundation above, and rolled theming out to every brand.
Trade open flexibility for controlled flexibility
Injecting CSS through props was blocking any update or scaling, so we deprecated it and replaced it with variant props and flexible tokens. Teams could still adapt components, but only through choices the system defined. For new development, manual overrides and hardcoded CSS values were no longer allowed.
Enforcement. Pull request reviews held the line, with the team’s help, backed by CI/CD gates running linting and Stylelint on both the library and the client app.
Make Figma the source of truth
To keep design and code from drifting apart, I wrote scripts that pull token data from Figma through its REST API and generate a specification file in the W3C Design Tokens Community Group format, convertible to any platform: web, Android and others.
Icons too. The same pipeline downloaded the icon set through the Figma API for an icon component to consume. Both pipelines were built by hand, before AI tools were part of my workflow.
Documentation. The library’s monorepo published utilities, a Storybook and a Docusaurus documentation portal alongside the components.
Narrow the scope
Other teams resisted adoption, and the agency-wide label was creating confusion within my own team. So I stopped treating it as an agency library and focused it on the automotive client, where it could deliver real efficiency. Wider reuse would be reconsidered when a real opportunity came up.
05What I’d do differently
Since I inherited this initiative, most of my lessons are about how a shared library should start.
Secure time, budget and collaborators up front.
A cross-project library with no dedicated budget and no committed partners depends on goodwill and spare time, and both run out under client deadlines.
Never start development without designers.
Building the library before the design system created debt that still isn’t fully paid. Design and code need to grow together from day one.