Why Libraries Earn Distrust In short: Shared libraries fail for three repeatable reasons — business logic leaking in, dependencies leaking out, and an accidental public API. Each one is preventable, and the first symptom is always the same: people quietly stop upgrading. Every organisation starts a shared UI library with the same reasoning, and the reasoning is sound. Instead of building the same table, dialog, and button in every application, build them once and reuse them. For a while it works. Development speeds up. The UI looks consistent. Then something breaks that nobody expected, and the mood changes permanently. How trust dies The lab testing team asks for a small change to : highlight "Grade A" milk in green and "Reject" in red. Reasonable request, five-minute change. The maintainer adds a condition to the dropdown's template: Ships as a patch release. Two days later the billing team updates their packages. Their invoice dropdown contains a status called "Rejected" — and now every rejected invoice is red, in a design where red means overdue . Their finance users start escalating payments that are not overdue. Nothing threw an error. No test failed. The library did exactly what it was told. The damage is not the CSS. It is that the billing team learned that a patch release from the platform team can change their screens in ways they cannot predict . From now on they pin the version. Six months later they are eleven versions behind, and every upgrade attempt is a week of work, which means it never happens. The three failure patterns Audit enough failing libraries and the same three show up. 1. Business logic leaked in The example above. A dairy concept — milk grades — ended up inside a generic dropdown. Once one business rule is in there, the next is easier to justify, and within a year the "shared" library encodes three teams' domain rules and belongs to none of them. This is exactly what the Chapter 2 boundary lint prevents: may only depend on and . But note the failure above did not even need an import — it was a string literal. Lesson two adds a rule for that too. 2. Dependencies leaked out A developer needs a chart, so they add a charting library to . Now an application that only wanted a button inherits the charting dependency in its , its lockfile, and its security scanning. The visible cost is bundle size, and modern tree shaking mitigates that more than people assume. The real cost is coupling of release cycles . When the charting library publishes a security advisory, every consumer's dependency audit goes red — including the ones that only use the button. You now need every team in the company to upgrade at the same time to fix a component most of them never render. 3. The accidental public API The library exports everything, because is the easiest line to write. Consumers import an internal helper because their editor offered it. The maintainer refactors that helper a year later, and three applications fail to build. The maintainer broke a promise they did not know they had made. This is the subject of lesson three. The god component There is a fourth pattern that grows out of the first three, and it is worth naming separately because it feels like good service while it is happening. Instead of composable pieces, the library tries to satisfy every request with configuration. starts with and . A year later: Two of those inputs are business logic in disguise ( , ) — pattern one, arriving through the API instead of through an import. And the combinatorial problem from Chapter 3 means most of the resulting states have never been rendered by anyone. Chapter 5 is the antidote: composition instead of configuration. What distrust actually costs When teams stop trusting the library, they route around it. They copy the component's markup and CSS into their own feature. That looks like a small local decision. Here is the bill when the company rebrands and card corners change from 4px to 8px: Library trusted Library routed around --- --- --- Files to change 1 150, across 20 repositories Teams that must schedule work 1 20 Time to full rollout One release One or two quarters Screens that get missed 0 Always some Who finds the missed ones — A customer The library did not fail because the code was bad. It failed because people stopped using it, and they stopped because it surprised them. "But I thought a shared library was obviously worth it" This is not exactly wrong, and the instinct behind it is right — duplication is genuinely expensive. But the way it is usually reasoned about hides most of the cost. The mental model people carry is: building it once instead of five times saves four builds. That is real, and it is the smaller half. What the model leaves out is that a shared component has a permanent coordination cost that a duplicated one does not. Every future change has to be safe for consumers you cannot see, tested against use cases you did not design for, and released in a way twenty teams can…