Tailwind CSS in Production: Keeping Utility Classes From Making a Mess

Tailwind gets adopted because it's fast. You don't invent class names, you don't jump between files, and a small change happens in place. Six months into a real project, though, the same properties that made it fast start working against you unless someone pushed back.

We build Laravel + Vue apps with Tailwind on almost everything we ship. Here's what separates the codebases that stay pleasant from the ones where nobody wants to open the templates anymore.

Where it breaks down

Three failure modes, in order of how often we see them:

The 12-class button. One button component gets a spacing tweak, then a shadow, then a hover state, then a dark-mode variant, and now every copy of it carries a paragraph of classes. Copy-paste spreads that paragraph to five more places. Change the design and you hunt through fifteen templates.
Magic numbers everywhere. w-[347px], top-[13px], text-[#1a2b3c]. Every arbitrary value is a decision that broke out of the design system, silently and individually.
Conditional soup. :class bindings with six ternaries inline. It works right up to the point where you need to reason about what the component actually looks like in each state.

None of these are Tailwind's fault. They're what happens when the cheapest path (add one more class) is taken thirty times.

What keeps it sane

Extract components at the third repetition, not the first. Tailwind ships @apply specifically so you can do this with regular classes instead of fighting specificity:

.btn-primary {
  @apply inline-flex items-center gap-2 rounded-md px-4 py-2
         bg-indigo-600 text-white font-medium
         hover:bg-indigo-500 focus-visible:ring-2;
}

The threshold matters. Extract on repeat one and you invent abstractions for things you'll never reuse. Extract at repetition three and you're deleting duplicated classes in multiple places, which is a real win.

One vocabulary for shared elements. Buttons, form inputs, badges, cards, table cells: anything that appears in many places gets one definition. A form input is the classic case: label styling, invalid state, focus ring, disabled state. Define it once, then use it everywhere. The day the client wants larger focus rings (an accessibility request, and yes, it comes up), you change one rule instead of forty templates.

Arbitrary values are a code smell. Occasionally a w-[420px] for a one-off is honest. When arbitrary values start showing up regularly, something is off: either missing spacing/sizing tokens in the config, or a design drifting without anyone reconciling it. Push the value into the theme file where it can be named:

// tailwind.config.js
theme: {
  extend: {
    spacing: {
      sidebar: '18rem',
    },
  },
},

w-sidebar documents why the number exists. w-[288px] documents nothing.

Complex conditionals stop being templates. When a Vue component's class binding grows past two or three states, compute it:

const statusClasses = {
  active: 'bg-green-100 text-green-800',
  paused: 'bg-amber-100 text-amber-800',
  archived: 'bg-gray-100 text-gray-500',
};

The template reads :class="statusClasses[status]". States are now greppable, which matters when someone asks why archived rows don't have hover states.

What we stopped doing

We tried the "one class per line" template formatting and gave it up; diff noise outweighed readability. We also stopped using !important variants (!text-sm) to fix layout conflicts early; that's always a sign two components are fighting over the same element, and the fix belongs in the component boundary, not the class name.

And we keep PurgeCSS/JIT behavior in mind from the start: class names written dynamically, like `text-${color}-500` in a template string, silently vanish from production builds. Every one of those bugs looks identical (works locally, styling missing in prod) and costs an hour each time. Build class names as full strings or map them.

The summary is unspectacular: treat the class list in a template the way you'd treat any other code that gets duplicated. The third copy is the signal.