A component used on four hundred pages is a decision made once that ships four hundred times. Fix its contrast, and four hundred pages become more readable. Make it faster, and four hundred pages get faster. Get it wrong, and the same thing happens in the other direction, which is the part people forget. I think that leverage makes the component library the most valuable thing a user interface team builds, and I want to be specific about why.
What the leverage buys
Consistency, which is the obvious one and the least interesting. Users learn a product faster when its parts behave the same way, and a library is how that happens without a style police.
Accessibility, which I have written about separately. The common failures are component failures, and a library that cannot produce them removes them from every page at once.
Performance. The library is where the bytes are decided. A button that pulls in a date library because someone once needed it is a tax on every page that has a button. A library team that watches its bundle is watching every page's bundle.
Speed of change. The thing teams underestimate is how much faster everything else gets. A product team building on a solid library spends its time on the product. One building on nothing spends a third of its time rebuilding inputs and dialogs, slightly differently each time, and then maintaining all of them.
Where teams misjudge it
The misjudgment is usually about time. The library costs more at the start, because building a component well enough for four hundred pages is harder than building it for one, and the product team with a deadline does not want to wait. So the first few features get built without it, and then the library has to catch up to patterns that already exist, which is harder than leading them.
I think the answer is to treat the library as what it is, which is infrastructure, and to fund it before the first product that needs it rather than after the fifth. Nobody asks the pipeline team to wait until the product proves itself.
What it costs
Leverage cuts both ways, and the cost of a library is that its mistakes are also multiplied. A breaking change ships to every consumer. A performance regression lands everywhere at once. A component with a confusing interface gets used confusingly four hundred times.
So the library needs things a product does not. Versioning that is taken seriously, with migration paths. A review bar higher than the one for product code, because the blast radius is larger. And a governance process for what goes in, because the fastest way to ruin a library is to accept every component anyone offers it.
Who owns it
The library needs a team, not a volunteer. I have seen it tried as a side project, owned by whoever cared, and it works until that person is busy, which is always eventually. The team does not have to be large. It has to be real, with the library as its job, with the standing to say no, and with a relationship to the product teams that is closer to a product manager and customers than to a shared folder.
Why I would staff it first
If I had to choose between one more product team and a real library team, I would choose the library, and I think most organizations would choose the other way. The product team adds one team's worth of output. The library team makes every other team faster, and the effect grows with each team that builds on it. That is what leverage means, and it is rare enough in software that I think it should be taken whenever it is available.
Photo source: https://photos.robertstowe.com/colorado