Five mistakes teams make with CSS architecture

This is cheap to get right at the start and expensive to retrofit. These are the ones we run into repeatedly when we audit CSS architecture.

The question is rarely whether something can be built, but what it costs to keep running afterwards. It rarely shows up as a line item, which is exactly why it slips.

Where it usually goes wrong

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• Naming conventions prevent the specificity arms race
• Custom properties centralise the values you change most
• Never checking whether the fix actually worked

Deleting CSS should be as easy as adding it. Where this goes wrong is almost never a lack of knowledge. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

What to do next

What this looks like day to day

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Three things worth confirming about CSS architecture before you move on:

• Someone can say what the current setup is without going to look
• Deleting CSS should be as easy as adding it — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you are not sure where your systems currently stand on this, it takes us about an hour to find out.