SYSTEM 07
TAILWIND — THE TOKEN LAYER.
Useful for exactly one thing: making a design system's constraints impossible to ignore. Everything else people argue about is secondary, including the part about verbose markup.

//The actual benefit#
Hand-written CSS drifts. Someone needs eighteen pixels of spacing, writes eighteen pixels, and now the scale has a value that isn't in the design. Repeat across four engineers and six months and the spacing system exists only in the design file. A constrained utility layer makes the off-scale value harder to reach than the correct one, which is a far more reliable mechanism than a code review convention.
On Velocity this mattered because six people were touching the frontend with varying familiarity with the design system. Consistency stopped depending on everyone remembering the scale, and started being the path of least resistance.
//The objection, addressed#
Yes, the markup gets verbose. In practice that traded against jumping between a component and a stylesheet, and against the specificity puzzles that come with a large hand-rolled CSS codebase. The trade was worth it on that team. On a solo project with a small surface I often skip it entirely — this site is hand-written CSS with custom properties for tokens, which achieves the same constraint with less machinery.
//Where it stops helping#
Complex keyframe animation, multi-step transitions, anything where the styling is genuinely dynamic and computed per frame. Trying to express those as utilities produces something worse than the stylesheet it replaced. I mix freely: utilities for layout and the token-governed properties, real CSS or inline transforms for motion.
And it's not a design system. It's a delivery mechanism for one. A team with Tailwind and no agreed tokens has consistent syntax and inconsistent design.