The fifth libraryEveryone rebuilds the component library. The argument against it was always about cost, and AI is quietly removing that argument.I have watched the same component library get built four times at four companies, by good engineers, none of whom were being careless. Buttons, modals, a data grid, a set of tokens nobody could quite agree on. Every time, the team knew other libraries existed. Every time, they built it anyway.Three reasons, and only one is stupid The first is ignorance: nobody knew the internal system existed, because it was owned by a team two orgs away with no docs and no changelog. Fixable and boring.The second is incentives, and it is the honest one. Nobody is promoted for adopting a library. You are promoted for shipping the feature. Adopting means a dependency on a team that may deprioritise you, an upgrade path you do not control, and an argument with a designer about why the button is that shade. Rebuilding is often the locally rational choice, and calling it laziness is a way of avoiding the org chart.The third is arrogance. We can do this better. Sometimes true. Usually it means we can do this more to our taste, which is a different claim wearing the same clothes.The objection that just stopped working The argument against rebuilding was always about cost. Six weeks you do not have, three engineers you cannot spare. That objection is dying. A model will produce a passable component library in an afternoon, and the thing that used to stop people — this will take a quarter — no longer does.The waste does not disappear when the build gets cheap. It relocates. It was never the writing that cost anything; it was the living in. Four nearly-identical modals nobody can safely delete, abstractions that were right for the first two cases and wrong for the next twenty, a design language that is really five design languages sharing a colour ramp. Commoditised design does not reduce that. It accelerates it, because the brake is gone.Anyone can say we can do better. Almost nobody finishes the sentence, and the finishing is the only part that separates a considered decision from the reflex. So here is mine, from a decade of shipping on these.Radix and Base UI are the same shape in different packaging. Both hand you behaviour — focus management, ARIA, keyboard handling — which is genuinely hard and genuinely solved. Neither hands you tokens or an aesthetic. Which means every consumer still builds the design system. They do not reduce the number of design systems in the world; they relocate the work, and let a team feel productive while doing it anyway.Shadcn is the interesting one, because it is the anti-library. Copying source into your repository optimises beautifully for the first day and charges you on every day after: no upstream fixes, no upgrade path, and every project’s copy diverging from the moment it lands. It does not merely permit fragmentation — its distribution model is forking. A tool whose adoption mechanism is a fork cannot be the last library.MUI’s problem is not Material, it is depth. The aesthetic sits so far down that theming becomes negotiation, and fighting it is the accurate verb. You adopt an entire opinion, or you spend the budget arguing with it.The axis none of them touch They are all React. That is not a criticism of their engineering, it is a ceiling, and it is the part that turns framework choice into a cause of the problem rather than a detail of it.Because teams do not only rebuild out of arrogance. They rebuild because the company moved from Angular to React, because there are three frontends in three stacks, because an acquisition arrived with its own. A design system bound to one framework has an expiry date printed on it, and that expiry is itself one of the main engines of reinvention. You cannot be the last library if you stop working when the stack turns over.Helix is web components. It runs wherever HTML runs.That is the bet, and it is the reason the four axes can be merged at all: behaviour, tokens that derive rather than enumerate, an aesthetic you can seed instead of fight, and a distribution model that does not require a fork. Those four things are currently split across four tools, and keeping them apart is paid for quietly, for years, by whoever inherits the result.I am building a design system.So the question I should be made to answer is the one I have been asking about everybody else: am I doing the same thing right now? I can find all three reasons in myself. Nobody is going to promote me for adopting somebody else’s. And I am fairly sure I can do it better, which is exactly what the last four teams thought.The bet has a real cost, and I would rather name it than wait for someone to find it. Web components put structure inside a shadow root, so anything that does not run JavaScript sees words without shape — which is precisely why every page on this site has a markdown twin generated from the same source it renders from. That is a workaround. An honest one, but a workaround.What I have instead of a clean answer is a test I am willing to be judged by. Not whether it is good — whether anyone who did not build it uses it, and whether it removes the reason to build the next one. If in three years Helix is a fifth library on the pile, then this was written by someone who did not recognise himself in it.