One mold, every casting: how we stopped redesigning the button
For a year, every page we shipped redesigned the same twelve parts. The fix was not a bigger design system — it was a smaller one, with a checklist and the nerve to say no.
The master mold for the current catalog. Every part on the site began as a casting from it.
Every team has the drawer: forty-one buttons, each built for one page, each slightly proud of its radius. Ours lived in production. Auditing it took a week and produced the least surprising finding in software — the differences were not decisions. They were weather.
The audit nobody wanted
We listed every part on every page and marked the differences worth keeping. Of 214 variations, 11 were deliberate. The rest were the same idea re-typed by different people on different Tuesdays, and each one cost maintenance forever.
A design system is not a library of answers. It is a short list of questions you have agreed to stop re-asking.
The mold came out of that list: one token file, a page template, and an automated check that fails a part the way a foreman rejects a bad casting — specifically, and before it ships.
What the check actually checks
Files first, then tokens, then class coverage: every class used in a preview must be defined by the part itself or a declared dependency. The rule sounds clerical until the first time it catches a part quietly depending on another part’s stylesheet — which was week one.
python3 check.py
136/136 components pass the moldThree rules did most of the work:
- Colors come from tokens, never from hex — themes stay possible.
- Every class a part shows is a class the part defines.
- A release needs three clean passes in a row, not one lucky one.
What we would not do again
We would not start with the logo, the marketing page, or 2,000 icons. We would start with the button, the input, and the argument about tokens — in that order, because the argument is the system and the rest is inventory.