Loading today’s stories
Build1 distinct publisher3 min readPublished
A retrospective on two and a half years of Lit Web Components, a custom element registry collision and a Figma-to-code pipeline shows how much careful engineering an unowned adoption problem can absorb.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Follow any of these and your For You feed starts watching them — no settings page required.
build
A missing package.json line broke every pnpm user of a React dashboard template1 distinct publisher
build
Linear spent 1,000 PRs making its components harder to restyle from the outside1 distinct publisher
product
150 Jenkins masters, one control plane: the fix for CI sprawl was not a migration1 distinct publisher
build
Four CSS systems in one bundle: the migration blocker was in the config, not the components1 distinct publisher
Start with the error, because it is the most portable thing in the account. Register the same Web Component from more than one package and the browser throws in the Custom Element Registry [12]. Shared icons triggered it, since multiple packages depended on them [12]. The fix landed outside the library: the shared package was declared a peerDependency and the dependency graph restructured so the application installed it only once [12]. The author's takeaway was about which dependencies in a monorepo must exist as a single instance [13]. Mine is narrower. The library could declare the requirement, but only the application installing it could actually satisfy that requirement, since the fix depended on how the dependency graph was structured downstream.
The framework decision has the same shape, and I think it was right. React would probably have given the fastest initial development speed [8]. It would also have locked out the Vue and Angular teams the project existed to serve, since the division had no single stack and kept rebuilding components with the same design [6][8]. Lit Web Components gave every application the same component interface regardless of framework [7]. That is a real cost paid for a stated reason, which is rarer than it should be. The component work was done from the ground up, with Ant Design and Spectrum source open alongside it [17].
Now the arithmetic. The work ran from spring 2022 to fall 2024, roughly thirty months [1][19]. The v2.0 release candidate arrived by the following spring, about twelve months in [11]. So something close to eighteen months came after the library was substantially built [20], and in that window no product adopted the broader system layered on top of it [2]. One team took the library, and that team was already preparing to launch [10].
The retrospective contains its own diagnosis without turning it outward. Writing rules in documentation does not tell you whether anyone follows them, the author notes, so when a rule is broken the system has to detect it automatically [14]. That is correct about component standards. It is also correct about adoption, which had no instrument at all. A CI check can fail a pull request. Adoption had no such enforcement: a product team's quarter went unaffected whether or not it migrated, and the platform side had no funded role to negotiate that it should.
What the extension bet on instead was mechanism. In early 2024 the author moved to a task force to extend the system [15], reading the structure and properties of a Figma design into an intermediate representation and generating code from it, because developers were still aligning code to Figma screens by hand [16]. There was also an 11 p.m. Korea time video call with a Figma engineer [18], which tells you where the hours went. That representation work became the starting point for the extended system [16], and the organization responsible was eventually disbanded [3].
Two caveats on reading any of it. The account is based on memory and is explicitly a personal retrospective rather than an official project report [5]. And the author went looking for comparable stories of systems that were built but never went further, and found very few [4], which is why the estimates most teams plan against come from the systems that landed.
Ranked by verification strength, evidence, and original report placement.
The author spent about two and a half years, from the spring of 2022 to the fall of 2024, building a design system.
The component library was released, but the broader system being built on top of it was never adopted by a product.
The organization responsible for the design system project was eventually disbanded.
The author looked for accounts of design systems that were built but never went further and found very few.
The account is based on memory, may be incomplete or inaccurate, and is a personal retrospective rather than an official project report.
In spring 2022 the company had no single frontend stack: some teams used React, others Vue or Angular, and because the stacks differed teams repeatedly built their own versions of components with the same design, including teams within the same division.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 31, 2026
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One participant, writing from memory, with the receipts locked inside a company he has left
The technical passages are specific in the way only first-hand work is — a duplicate custom-element registration traced to shared icons, a peerDependency restructure, an intermediate representation renamed from DST to DSML — and they describe browser behaviour a reader can verify independently of this author. Everything organizational is a different matter: no employer, no division, no repository, no release history, and the author's own warning that details may be incomplete. He is the only witness to his own project.
One team in, then the lights went out
Uptake peaked at a single internal adopter. The library reached a v2.0 release candidate and one team preparing a launch used it; the system built above it reached a demo and a project report and no product. Roughly eighteen of the thirty months came after that release candidate, and the end state is an unadopted system and a dissolved owning organization. The only reason this scores above zero is that the release candidate and that one adopting team are real shipped facts, not intentions.
Sells itself as a failure, describes competent work
The rhetoric runs below the substance rather than above it. A post titled around failure has no product to promote, no tool being launched, no metric being flattered — and it undercounts what it documents, since a framework-agnostic component library that reached a release candidate and a real adopter is a partial success wearing a defeat headline. The mild pull in the other direction is scope: a story about one division inside one unnamed company is easy to read as a general lesson about design systems, and the author's framing invites that.
Nothing to sell, and no one who can contradict him
The distortion pressures here are unusually light on the commercial side: the author has left the organization, holds no stake in Lit, Figma, Ant Design or Spectrum, and gains nothing from the reader adopting any of them. What remains is reputational — a shelved project reframed as instructive experience — plus the structural asymmetry of anonymising the employer. Every unflattering organizational judgement in this story is made about parties who cannot be identified and therefore cannot answer.
Trust the engineering, hold the org chart loosely
Two tiers of reliability sit in one post. The mechanics — Lit for cross-framework reach, a registry collision from double registration, an AST-style intermediate representation feeding a code generator — are internally coherent and consistent with how these tools actually behave, so we hold them fairly firmly. The dates, the count of adopting teams and the reason an organization was dissolved rest entirely on one person's recollection of events inside a company nobody else in this coverage has looked at.