Organizing Tailwind CSS in Larger Projects

Tailwind takes flak for messy class soup, and the criticism is fair when teams skip the conventions. Set a few habits early and Tailwind scales fine to large codebases. Here is what I use.

Component composition over @apply

When the same combination of classes appears in three places, extract a component, not a CSS class with @apply. The component carries the meaning ("PrimaryButton"), and the classes stay where Tailwind can purge them. @apply tends to be a slippery slope back toward custom CSS — once you start using it, you stop using Tailwind.

Design tokens in tailwind config

Define brand colors, spacing, and typography in tailwind.config.ts (or in the @theme directive in v4). Reference them as text-brand-primary, p-section, font-heading. When the design changes, you change the config, not 200 component files.

Order classes consistently

Use the official Tailwind Prettier plugin. It sorts classes in a consistent order across the codebase. Without it, every developer orders them differently and reading diffs becomes harder than it needs to be.

Extract complex variants

When a class list grows past 8-10 utilities, especially with hover/focus/active variants, the readability tanks. At that point, factor it into a component with named props. Component design is what scales — not class patterns.

What I avoid

Custom utility classes for one-off styles. If something is truly bespoke (a complex gradient, a specific animation), it belongs in CSS, not in Tailwind config. Tailwind is for the 90% of common patterns. Reserve custom CSS for the 10% that benefits from it.