A component library used by six engineers is a folder. A component library used by 160 engineers is a treaty. Rosetta taught me that the second kind is barely a technical artifact at all — it's an agreement about how an organization decides what things should look like, dressed up as an npm package.
Every prop you ship is a promise you'll keep for years. The most durable components in Rosetta were the ones with the fewest opinions: a variant enum instead of a dozen boolean flags, tokens instead of raw hex values, composition instead of configuration.
Rosetta shipped three themes from one component tree. That only works when themes are pure data — no theme-specific components, no if (theme === 'dark') branches hiding in render functions. The theme object is the single source of truth; components are just projections of it.
The library you ship is the smaller half of the work. The library people keep choosing is built in code review, office hours, and changelogs.
Adoption is never mandated; it's earned. What worked: migration codemods with every breaking release, a public roadmap anyone could comment on, and treating internal teams like customers with churn risk. What didn't: decrees, and any sentence that started with "going forward, all teams must."
Nothing moved adoption like a live walkthrough of a real team's migration. Recorded sessions became the library's best sales channel.
Thirteen years in, this is the part I'd tell my younger self first: the system survives when the people using it feel like its owners, not its subjects.
Building something at the frontier, or hiring the person who will? Reach out.