Why Internal Component Libraries Die
The failure mode I've seen most often: a library built by one team for their use case, then pushed to everyone. The other teams work around it. The workarounds become the standard. The library gets ignored. Nobody wants to be the person who says 'our component library is dead' so it just slowly becomes irrelevant while everyone quietly uses their own implementations.
The second failure mode is over-engineering the API surface early. Components with thirty-five props that handle every conceivable variant. Teams read the docs, get confused, and build their own simpler version. The library became a burden instead of a shortcut.
The One Decision That Changed Adoption
For the third library, we made one rule before writing a single component: nothing goes in until two different teams have the same need. We called it the Rule of Two. A component was only generic enough to be in the library if at least two teams independently asked for it.
This changed how the library was perceived. Instead of something imposed from above, it was something that grew from actual team needs. When a team's request became a library component, they felt ownership. Adoption stopped being a mandate and became natural.
Key takeaways
- The Rule of Two: only add a component to the shared library when two independent teams need the same thing — this keeps the API surface real rather than theoretical
- Assign a named owner per component, not a committee — committees mean nobody is responsible when something breaks or becomes outdated
- Write the usage example before writing the implementation — if the API is awkward to write in the docs, it'll be awkward to use in production
Conclusion
The best component library is the one your team actually uses. That's a product problem as much as a technical one. Start from real needs, keep ownership clear, and never add a component you can't point to two distinct usages for.
Enjoyed this article?
Vivek Kumar Singh
Technical Expert · Full Stack Cloud Engineer · Tokyo, Japan
