Design System Platform for 50+ Teams

Model response

That is a genuinely defensible position and it is right in some organizations. Shared tokens plus independent components gives you visual consistency at near-zero coordination cost, and if the teams are building genuinely different products it may be the correct call. What it does not give you is shared accessibility and shared behavior correctness — a focus trap, a combobox, a date picker are each weeks of work and each gets subtly wrong in fifty places. My split is intended to get both: tokens plus headless behavior primitives are centralized because they are expensive and universal, and the styled layer is thin enough that a team can build their own on top if they need to. The condition where you would be right and I would be wrong is if the styled layer starts generating more support load than the primitives save, and I would watch contribution latency and fork count to detect that.

Model response

That is accurate and I would not oversell them. A codemod that renames a prop is trivial; a codemod that changes a component's composition model cannot be fully automated, and pretending otherwise is how you lose credibility. Two things follow. First, the codemod's real job is to make the remaining work legible — it should annotate what it could not transform with a comment linking to the migration doc, so a team knows the scope in an hour instead of a day. Second, if a change cannot be mostly automated, that is strong evidence the change is too expensive at fifty-team scale and I should ship it as a new component alongside the old one instead of as a breaking change. The codemod is a forcing function on my own API decisions as much as it is a migration tool.

Model response

Fair, and if this were a ten-team org I would ship CSS Modules and plain components and skip the headless layer entirely. The reason I would not skip it at fifty teams is that the cost is asymmetric and back-loaded. Adding a behavior layer later means rewriting every component's internals, which is exactly the kind of change that cannot be codemodded and therefore cannot be shipped. The zero-runtime decision is similar: it is nearly free to choose at the start and extremely expensive to retrofit once fifty apps depend on runtime theme switching. I would still cut scope hard on component count — ten components done properly beats sixty done thinly — but the two structural decisions I would make upfront, because they are the ones I cannot reverse.

Model response

The concern is legitimate and I have seen adoption dashboards read as a performance metric on teams, which poisons the relationship immediately. Two mitigations that actually matter. First, scope: the scanner reports package version and imported symbol names, never source code, and I would publish exactly what it collects. Second, framing and ownership: the data exists to size migration blast radius and to prioritize what we build, and I would commit to never using it to rank teams. Practically I would make it opt-out and expect a few holdouts, then treat a low opt-in rate as a signal that the relationship is broken rather than as a data problem to engineer around. If I cannot get voluntary participation, the honest fallback is npm download counts plus a quarterly survey — worse data, but data that does not cost trust.