Seven teams, four audiences, one platform
A B2B electronics platform is not one product with one user. A professional buyer searches and compares. A procurement team needs approvals, budgets and a paper trail. An account administrator manages who in their company may order what. Customer care works the same surfaces from the other side, under time pressure, to fix something.
Seven product teams serve those four audiences, and each team is right about its own. Left alone they converge on seven reasonable answers to the same question, and the person who crosses between them, which is every one of those four, pays for the difference. A design system is how a platform stops charging its customers for its own org chart.
That is the problem Fuse is for. The component count is the means.
Agreed across three functions that do not report to me
The system crosses Product, Engineering and IT. None of those report to me, which makes agreement the actual work and the component library the easy part.
What made it hold was giving each function the thing it needed to say yes. Product needed the teams to go faster, not slower, which is a rollout sequenced so no team is asked to stop and refactor. Engineering needed the component code to be theirs, auditable and debuggable, with no vendor in the critical path. IT needed the system to sit inside the existing stack and its security and accessibility obligations, not beside them. Executive sponsorship and budget were secured before any of that was asked for, because a conversation about how to adopt a system is a different conversation from whether to fund one.
One system, in Figma and in the repository
Fuse is built on shadcn-vue, which puts the component code in Conrad’s own repository. It can be audited, themed and fixed without waiting for a vendor release.
The design side and the code side are one system, not two artefacts that resemble each other. A token changed in Figma has a named counterpart in the repository, a component has one definition each side, and drift between them is something the workflow below is built to find. Two sources of truth is the normal failure, and it is the one that makes a platform feel assembled from parts.
The cost of owning the code is real and worth stating plainly: the team owns maintenance it could have rented. For a retailer with a long catalog tail and accessibility obligations that attach to the whole of it, owning the maintenance is the cheaper risk. A vendor’s release cycle is a dependency in the middle of a legal obligation.
What is in it, starting underneath the components
Two foundations were replaced before any component was drawn, because a system inherits whatever it is built on.
The typeface. The brand ran on Conrad Basis, a licensed face sourced for print. On a digital platform that is a recurring licence cost and a seat to track, for letterforms drawn for a medium the platform is not. It was replaced with Inter, a typeface made for screens. The licence cost went away, and every team now has the same face in Figma, in the repository and in anything a partner builds against the brand.
The icons. There was a small hand-drawn set, inconsistent in weight, grid and metaphor, and any team needing an icon it did not contain drew its own. The system moved to Font Awesome: one library, one weight, one grid, and something to reach for in the case nobody anticipated. The drawing stopped, and so did the arguing about it.
Neither is the kind of thing anyone demos, and both are why a platform reads as one platform before a single component loads.
On top of that: 35 components, with a component workshop so contributions have somewhere to land, and CI/CD so they have a way to be checked before they arrive. Seven product teams are in scope.
Contribution governance, written down
I wrote the rollout plan for the CTO: architecture, staffing and contribution governance.
The governance model answers the three questions a team actually arrives with. Who owns the system, so there is one named group accountable for it. Who may change it, which is any product team, through a proposal that goes to the component workshop and through CI/CD before it is in anyone else’s build. And what happens when a team needs something the system does not have, which is a documented local variant with a review date, so the team is unblocked that week and the system learns from it, with no fork to live with afterwards.
Without those three answers a system becomes a bottleneck the first time somebody is in a hurry, and the first fork follows within a quarter. With them a team that disagrees has a route that ends inside the system.
AI pointed at the maintenance burden
I built an AI-assisted workflow connecting Figma to Claude Code: checking component usage against the system, finding drift between what is designed and what is built, and generating the parts of documentation that are tedious enough to otherwise go stale. Every change is controlled and reviewable.
It is pointed at the maintenance burden, because that is where design system hours actually go. This site runs on the same workflow.
Decisions
Four places where the design argument changed what was going to happen.
Fund it as a product, then build it. Planned: start on components and demonstrate value, the way most systems begin. Argued: a system without a sponsor, a budget and a mandate becomes a side project three designers maintain in their own time, and I had watched that risk up close while building Sunscreen. The case belonged in the currency the business already uses: seven teams paying the same component bill. Happened: executive sponsorship and budget were agreed before the first token. The rollout conversation was about how, never about whether.
Replace the brand typeface, do not license it for the web. Planned: extend the print typeface licence to cover the digital platform, because the brand was already defined around it. Argued: the face was drawn for paper and priced per seat, so the platform would pay forever for letterforms that were never made for a screen, and every partner building against the brand would have to buy in as well. A brand is recognizable by more than one typeface. Happened: Inter across Figma, the repository and partner material. The recurring licence cost is gone and the brand reads the same everywhere it is set.
Own the component code, do not rent it. Planned: adopt a component library and take its release cycle with it. Argued: the obligation covers every page of a long catalog, and no vendor roadmap is going to prioritize the tail of somebody else’s product. Renting the layer puts another company’s release schedule between us and a legal deadline. Happened: shadcn-vue, so the components ship from the repository the team already deploys from, and a fix needs nobody’s permission.
Point the AI at the maintenance burden. Planned: the obvious use, generating components faster. Argued: design system hours go into drift, audits and documentation that goes stale. Generating more components adds to the pile a system has to keep consistent. Happened: a Figma to Claude Code workflow that checks usage against the system, finds drift between designed and built, and drafts the tedious documentation. Every change is reviewable.
Where it stands, including the part that is not finished
Fuse is live and in its first year, which is the honest status. The number it will eventually be judged on is the one FTI’s system could show after a year, and it does not have that yet.
The design layer is complete: foundations, components, tokens, the workshop, the governance model and the rollout plan. The engineering workstream needs a dedicated owner to carry adoption at the same pace, and that gap is on the table with leadership, named out loud and early. Naming a resourcing gap early is cheaper than discovering it in the second year, and a system that out-runs the capacity to adopt it is a fork waiting to happen.
What it does have is the thing FTI’s system took a year of arguing to get: a sponsor, a budget, a governance model, and a rollout plan the CTO has read.