Tailwind CSS Launch Checklist: 25 Essential Steps

Extend (do not override) the default theme with your brand colors, spacing scale, font families, and border radii. Use semantic names like `primary`, `surface`, `destructive` instead of raw color values. This makes the design system consistent and refactorable.

In Tailwind v4, ensure your CSS imports cover all files that use Tailwind classes. In v3, configure `content` in tailwind.config.js to include all jsx, tsx, html, and mdx files. Missing paths cause classes to be purged from production CSS.

Define colors as CSS custom properties (`--color-primary: 204 100% 40%`) and reference them in your Tailwind theme. This enables runtime theme switching (dark mode, user preferences) without generating duplicate utility classes.

Audit your `@layer components` and `@layer utilities` directives for classes you defined but never use. Custom layers bypass tree-shaking — unused custom classes end up in your production CSS.

Audit your templates for arbitrary values like `p-[13px]` or `mt-[7px]`. Replace them with the nearest Tailwind scale value (p-3, mt-2). Arbitrary values break visual rhythm and make the design harder to maintain.

Resize your browser through sm (640px), md (768px), lg (1024px), xl (1280px), and 2xl (1536px). Also test at 320px for small phones. Look for horizontal overflow, overlapping elements, and text that becomes unreadable.

Tailwind is mobile-first — base classes apply to all sizes, and breakpoint prefixes override upward. Verify you are not overriding mobile styles unintentionally. Read your classes left to right: base, then sm:, md:, lg:, xl:.

Buttons, links, and interactive elements should be at least 44x44px on touch devices. Use `min-h-11 min-w-11` (44px) as minimum sizes. Small touch targets cause frustration and are flagged by Lighthouse accessibility audits.

Use `container mx-auto` or `max-w-7xl mx-auto` to prevent content from stretching across ultra-wide displays. Set appropriate padding (`px-4 sm:px-6 lg:px-8`) so content does not touch screen edges on any device.

Verify headings and body text are readable at all breakpoints. Use responsive text sizes like `text-2xl md:text-4xl lg:text-5xl` for headings. Ensure line lengths stay between 45-75 characters for readability using `max-w-prose` or similar constraints.

Add `dark:` variants for all color-dependent classes. Do not just invert colors — redesign for dark backgrounds. Verify all text meets WCAG AA contrast ratios (4.5:1 for normal text, 3:1 for large text) in both modes.

Use `focus-visible:ring-2 focus-visible:ring-primary` on all interactive elements. The default browser focus ring is often removed by CSS resets. Without visible focus indicators, keyboard users cannot navigate your site.

Add `sr-only` class to text that provides context for screen readers but should be visually hidden. Icon-only buttons, for example, need `<span class='sr-only'>Close menu</span>` so screen readers announce the button's purpose.

Do not rely solely on color to communicate errors, success, or selection. Add icons, text labels, or border changes alongside color changes. Color-blind users (8% of men) cannot distinguish red from green reliably.

Wrap animations in `motion-safe:` or use `motion-reduce:` to disable or simplify animations for users who have enabled reduced motion in their OS settings. This includes transitions, transforms, and scroll-triggered animations.

After building, check your CSS file size. A well-configured Tailwind project should produce 10-30KB gzipped CSS. If larger, check for safelist overuse, unused custom utilities, or third-party CSS that should be loaded separately.

Safelisted classes are never purged, even if unused. Common misuse: safelisting all color variants 'just in case'. Instead, use complete class names in your code (`bg-red-500` not `bg-${color}-500`) so the scanner can find them.

When you find the same long string of Tailwind classes repeated 3+ times, extract them into a React component or use `@apply` in a CSS layer. This improves maintainability and can reduce HTML size in server-rendered apps.

Ensure your build tool (PostCSS, Vite, webpack) minifies CSS output. Modern tools do this by default in production mode. Verify by checking the built CSS file — it should be a single line with no comments or whitespace.

Never build class names dynamically like `bg-${color}-500` — Tailwind's compiler cannot detect these and will purge them from production CSS. Always use complete, literal class strings. If you need dynamic styles, use a mapping object that maps values to full class names.

Add `prettier-plugin-tailwindcss` to automatically sort your Tailwind classes in a consistent order. This eliminates class ordering debates, makes diffs cleaner, and helps developers find specific utilities quickly.

Install the official Tailwind CSS IntelliSense VS Code extension. It provides autocomplete, syntax highlighting, linting, and hover previews for all utility classes. This catches typos and invalid classes during development.

Create a reference page or Storybook story showing all your custom colors, spacing values, and typography scale. This helps new team members use the design system correctly instead of inventing arbitrary values.

If upgrading to Tailwind v4, check for breaking changes: config file format changed, `@tailwind` directives replaced with `@import 'tailwindcss'`, arbitrary values syntax updated, and some utility names changed. Run the official migration tool.

Disable CSS in your browser and verify the page is still usable (proper heading hierarchy, logical content order). Test on slow 3G to ensure CSS loads quickly. A utility-first approach means your HTML is semantic even without styles.