Is Tailwind CSS Worth It? An Honest Answer After Dozens of Builds

Few tools split developers like Tailwind. I have shipped production sites both with it and without it, inherited codebases in both styles, and handed both kinds over to other teams. The honest answer is that it solves a real problem very well and creates a smaller one you need to manage.

The problem it actually solves

Not typing speed — naming and deletion. In a traditional stylesheet, nobody knows whether .card-inner-wrap is still used, so nothing ever gets deleted and the file grows forever. Utilities live in the markup, so when the component goes, its styles go with it. On a long-lived codebase that is the difference between a stylesheet you trust and one you are afraid of.

Where it genuinely wins

• Design system enforcement. Your spacing and colour scales are the only values available, so nobody invents 23px. That is the discipline argued for in white space and colour theory, enforced by the tooling.
• Component-based work. Styles sit beside the markup they belong to. No file switching, no naming debate.
• Small production CSS. Unused utilities never ship, so output stays roughly flat as the site grows.
• Handover. A new developer can read what an element does without hunting through a cascade of overrides.

Where it does not

• Content-heavy markup you do not control. Blog HTML from a CMS needs real element styles. The typography plugin helps; it is still a workaround.
• Long class strings. A div with eighteen utilities is legitimately hard to read. Discipline and component extraction are the answer, and not every team applies them.
• Complex animation. Multi-step keyframes belong in CSS or a library — see GSAP vs Framer Motion.
• Teams with a designer who edits CSS. Utilities move styling into templates, which may put it out of reach of the person who used to own it.

The readability objection, addressed

It is a real cost, and it is manageable. Extract anything used more than twice into a component. Keep a consistent class order (layout, spacing, typography, colour, state) and let a formatter enforce it. Use arbitrary values sparingly — [13px] everywhere means you are fighting the scale rather than using it.

What modern CSS changed

Nesting, custom properties, container queries, and :has() have closed part of the gap. If you are on a small site with a couple of developers and a clear design system, plain modern CSS is a perfectly professional choice and one less dependency to maintain. Tailwind's advantage grows with team size, project lifespan, and component count.

How I actually decide

1. Component-driven app or site, more than one developer, expected to live for years → Tailwind.
2. Small marketing site, one developer, heavy bespoke art direction → modern CSS.
3. Existing codebase → whatever it already uses. Mixing paradigms is worse than either choice.

The tooling matters far less than the consistency. A codebase where every developer solves layout the same way beats a codebase with the fashionable tool and no conventions — the same lesson as letting a theme make your decisions for you.

Inheriting a codebase and not sure whether to keep its approach? Ask me for a read.