The failure mode is never the component library
It is starting one without a sponsor, a budget or a mandate, and watching it decay into a side project that three designers maintain in their own time. Component libraries are not hard to build. Keeping one alive through a reorganization, a budget round and a change of CTO is hard, and that is an organizational problem with an organizational answer.
So the sequence is always the same: make the case, get it funded as a product with a team and a backlog and a number it has to show, and only then name a token.
I have run that sequence twice, in organizations that had almost nothing in common.
Fuse, at Conrad Electronic. Seven product teams on one platform, shadcn-vue so the component code sits in Conrad’s own repository, 35 components with CI/CD, and a rollout plan written for the CTO. In its first year.
Sunscreen, at FTI Group. 90 subsidiaries, a React library for a Next.js stack, a funded product team of eight, 356 components, and a measured return above 170 percent in its first year.
A third, at Smart InsurTech, went in as design foundations alongside the research practice while the company was learning to work as a product organization.
What a company pays without one
The bill is never itemized, which is why it gets paid for years without anyone deciding to.
The same layer gets built once per team. A date field, a data table, a dialog, a filter. Seven teams, each right about its own domain, each writing a component the other six already have. The first build is not the cost. The cost is that one component now has seven owners, seven behaviours and seven sets of edge cases, and every later change has to find all of them.
Accessibility gets bought once per implementation. An obligation that attaches to a whole catalog cannot be discharged component by component. One contrast failure written independently in seven places is seven fixes, seven reviews and seven chances to miss one, and the next audit starts from zero again.
The customer pays for the org chart. Somebody who crosses between domains, which in B2B is the same buyer doing procurement, administration and support, meets a different answer to the same question in each one. Nobody designed that. It is the sum of reasonable local decisions, and it reads to a customer as a platform assembled from parts.
Design spends its time on what already exists. A team without a component layer specifies one every sprint. That is the work nobody counts, because it never appears as a project. It appears as design being slow.
And there is no number to argue with. This is the part that keeps the bill unpaid. The cost is spread across every team’s velocity and every quarter’s roadmap, so it is invisible until somebody converts it into the currency the business already uses. That conversion is where this work starts, and it is the piece most systems skip.
At FTI Group the alternative was measured: the group design system returned above 170 percent in its first year, and that figure is why it kept its funding through a difficult year. At Conrad Electronic the arithmetic is seven teams and one component bill.
A note on the public evidence, since it is tempting to borrow: there is very little of it. The widely quoted percentages on design system savings trace back to a handful of vendor blog posts citing each other, and the one controlled test I can find used eight developers building a single form. A number on your own system, measured in your own organization, is worth more than all of it, and is the only kind of number on this site.
What is the same every time
Funding before tokens. At FTI the argument was the integration tax across 90 subsidiaries. At Conrad it was seven product teams rebuilding the same component layer. Different arithmetic, same conclusion, and in both cases the money came before the work.
A number the business already uses. Return on investment, time to market, adoption rate. Not component count, which measures effort.
Adoption is earned. Teams adopt a system that visibly saved another team time. They fork a system they were told to use, and then there are two systems.
Governance written down. Who owns it, who may change it, what happens when a team needs something it does not have. A system without that answer becomes a bottleneck the first time somebody is in a hurry.
What differs, and why it matters
The two are not the same project twice. The stack is different, the funding argument is different, the scale is different, and the outcome is at a different stage. That is the useful part: the sequence held while everything it was applied to changed.
Conrad’s system has to earn its place against a platform that could out-ship it, and the case was argued to a CTO. FTI’s had to earn adoption across a federation that could ignore it, and the same case had to be made to ninety of them. One is in its first year and honest about that, the other is finished and measured.
Having built one twice is the claim neither project makes on its own. The second was faster, because the sequence was already known.