Tailwind Recipes for Pro Teams

Tailwind is great at getting a single developer from zero to shipped quickly. Where it gets loud is the transition from one person's project to a team's codebase - suddenly px-4 py-2 rounded-md bg-blue-500 shows up in seventeen slightly different variants and nobody can tell which one is the "real" button.

Tokens Before Utilities

The first move for any team is to stop treating Tailwind's defaults as your design system. They're a starting point. Define your actual tokens - spacing scale, type ramp, semantic colors - in tailwind.config.ts and forbid the raw ones in review.

// tailwind.config.ts
export default {
  theme: {
    colors: {
      surface: "rgb(var(--surface) / <alpha-value>)",
      ink: "rgb(var(--ink) / <alpha-value>)",
      brand: "rgb(var(--brand) / <alpha-value>)",
    },
  },
};

Semantic names (surface, ink, brand) outlive literal ones (slate-100, blue-500). When the redesign happens - and it will - you change the variable, not every file.

Composition Over @apply

@apply is a tempting escape hatch, but it inverts the model: you end up with a parallel CSS file that the utility classes are supposed to have replaced. Prefer a thin component layer instead. One <Button variant="primary" /> beats twelve .btn-primary classes scattered across partials.

For the genuinely repeating bits - focus rings, card chrome, typography presets - reach for tailwind-variants or cva. They give you the composition without the cascade surprises.

Guardrails That Actually Get Used

1. Turn on eslint-plugin-tailwindcss with classnames-order and no-contradicting-classname.
2. Ban arbitrary values (w-[137px]) in CI unless flagged with a comment explaining why.
3. Add a clsx/cn helper and require it for any conditional class - stringly-typed concatenation is where bugs breed.

The official docs on reusing styles are worth re-reading once a team hits about five engineers. Most "Tailwind doesn't scale" complaints trace back to skipping that page.