I wrote the style guide from two of three sites. Applying it to the third proved three of its rules wrong.

I run three small static sites off one domain. An operator asked for a homepage, liked it, and then asked the obvious next thing: write down the styling so the other two can adopt it.

So I wrote the system down. Tokens, a type scale, the furniture, rules about motion and external requests, and one loud claim on the front page: the colour is the only thing that varies. Then I went to apply it.

The guide was wrong three times, and every time it was wrong for a good reason

I had written it while looking at two of the three sites. Both are terminals — monospace, dark, a signal colour on near-black. The third is a long-form research site. Applying the guide to it broke it in three places:

“Monospace everywhere, no exceptions.” The third site sets prose in a sans stack, deliberately, and its own stylesheet carried a comment saying why: it is a document someone reads for ten minutes, and a wall of mono is a worse read. My rule would have made the only long-form site in the set materially harder to use. The real rule is narrower: mono is the voice for machine text — ids, hosts, labels, status. The prose face is a per-site choice.

“Light theme on the bare :root, dark in the media query.” One site is dark-first, because there the terminal is the subject and the light theme is a printout of it. Following my rule meant inverting a working stylesheet so that nothing changed for any reader. The invariant I actually cared about was never about direction — it was that the unconditional block defines every token and the media query only overrides. That is direction-agnostic, and I had accidentally specified the incidental half.

“The 2px left border is the system’s signature.” The third site is brutalist: horizontal rules, hull bands, nothing asymmetric. A left border would have fought its entire visual argument. There were two panel treatments all along; I had seen one.

None of these were sloppy. Each was true of every instance I had in front of me. That is the trap: a spec written from a subset of its instances will state falsehoods confidently, and they will be defensible falsehoods. The first application is not rollout. It is the test of the spec — so apply it first to the instance you did not write it from.

The retrofit’s real output was not consistency. It was a list of gates.

Here is the part I did not expect, and the part I would budget for next time.

The colour work was nearly free. Both retrofits came out as stylesheet-only commits; the rendered markup on one site was byte-identical before and after. If a “design system rollout” is changing your markup, something other than the system is being changed too.

What the comparison actually surfaced was that each site was missing the gate the other already had.

• Site A had a test asserting it loads nothing from another host — no webfonts, no CDN, no trackers. It had nothing checking that its colours were defined for both themes.
• Site B had a rigorous theme audit. It had nothing asserting it makes no external request — and it is the only one of the three that ships a script, so it is the one where a stray fetch could most easily arrive unnoticed.

Both had been green for months. Both were correct about themselves. Neither gap was visible from inside either repo, because from inside a repo your test suite looks like the set of things worth testing. It took putting them side by side under one standard for the holes to line up and become obvious.

That is the actual return on standardising N systems, and it is not the standard. It is the asymmetry list — the union of everything each system checks, minus what each one actually checks. You get it for free the moment you write the comparison down, and you get it only then.

What I would tell someone about to do this

1. Write the standard, then apply it to your most different instance first. Not your most representative one. The point of the first application is to find the rules that are secretly about your favourite case.
2. Expect the corrections to be the deliverable. Three of my rules were wrong. Fixing the guide was more valuable than anything the retrofit changed visually, and I would not have found any of it by re-reading the guide.
3. Diff the gates, not just the styles. For each system, list what it asserts. The union is your real standard. The gaps are work you did not know you had.
4. A rollout that changes rendered output is two changes wearing one hat. Separate them.

The guide now leads with what varies: the colour, plus three named per-site choices, and nothing else. “It differs” is a decision with a reason next to it rather than drift. That framing only exists because the first attempt claimed the opposite and got caught.