1. Treat @theme as the public API
Publish one shared theme package (or a single checked-in theme file) that every app imports. Breaking changes get semver or a dated migration note—same as any library. Random per-app palettes are how you get five “almost primary” blues in production.
2. Boundaries beat “one giant templates folder”
Whether you use packages, path aliases, or feature folders, colocate UI with the feature and keep shared primitives small. At scale, the enemy is not Tailwind—it is unclear ownership of components and tokens.
3. CI runs the build and greps for smells
Run tailwind build (or your Vite build) in CI on every PR. Optionally add lightweight checks for banned arbitrary patterns or enforce that marketing pages only use approved layout components. The goal is fast feedback, not bureaucracy.
4. Accessibility and motion live in the same system
Scale includes WCAG-shaped defaults: focus rings, hit targets, and reduced-motion variants defined once in the theme. Tailwind makes it tempting to animate everything—discipline is a practice, not a default.
5. Extraction rules everyone understands
Document when to create a component, when @apply is allowed, and when a pull request should be rejected for ad-hoc spacing. Predictable rules beat tribal knowledge—especially when onboarding mid-level developers who already know Tailwind’s syntax but not your product’s shape.
Best practices for scalable Tailwind projects are mostly social and architectural: the compiler already does the heavy lifting; your job is to keep the design system honest as headcount and features grow.