I get asked about Tailwind a lot. Usually some variation of “do you use it,” sometimes “why do you not use it on this site,” occasionally “is it dead yet” (no, it is not, please calm down).
The honest answer is that I use it, but not for everything, and the where-and-why is more interesting than the yes-or-no. So here is the actual breakdown of what I reach for it on, and what I drop it for.
Where Tailwind is genuinely good
Prototyping. This is the obvious one. If I am building something to show a client on Monday morning and it is Sunday night, I am not setting up a custom design system. I am opening a fresh project, throwing tailwindcss in, and slapping class="flex items-center gap-4 p-6 rounded-lg bg-slate-100" onto everything until it looks roughly correct. The speed is real. I can have something presentable in two hours that would have taken me a full day with hand-rolled CSS.
Internal tools. The admin dashboard for one of my own projects (a small invoicing thing I built for myself in 2024 because I was tired of Wave‘s UI) is pure Tailwind. Nobody sees it but me. The CSS does not need to be elegant. It needs to exist, render, and let me click buttons. Tailwind is fine for that.
Single-purpose admin UIs in general. CRUD interfaces, data tables, settings panels, login screens. Anywhere the design is going to keep changing and the interface is functional rather than expressive.
And this one matters: anything where design churn is constant. If a client (or my past self, more likely) is going to redesign the same page nine times, Tailwind makes that nine-times-redesign cost about a third of what it would be in a stylesheet, because I am not maintaining names for things. I am just describing them in place.
Where I drop it
Content sites where typography matters.
Pivotlog itself is the example. This site runs on a hand-rolled theme, no Tailwind, with an actual stylesheet and class names like .post-body and .tag-list and .byline. Why? Because when I am tweaking the line height on the body copy at 1am because something looks ever so slightly off, I want to open one CSS file and change one number. I do not want to grep for leading-7 across forty templates and decide whether I should make it leading-[1.65] or add a custom utility to the config or just leave it broken.
Typography is one of those things where the markup needs to be readable. <p class="text-lg leading-relaxed text-slate-700 mb-6 max-w-prose font-serif"> tells me less, at a glance, than <p class="post-paragraph"> with a stylesheet that defines what a post paragraph is. The semantic version is shorter, more readable, and the styling is in one obvious place. For a blog, where 90% of the markup is paragraphs, this matters.
Projects with a designer providing a design system. If somebody has handed me a Figma file with named tokens, defined components, a type scale, and a color palette, I want my code to mirror those names. .btn-primary matches the design system. bg-blue-500 hover:bg-blue-600 text-white px-4 py-2 rounded-md font-medium does not, because the design system thinks of it as one thing and Tailwind makes it ten things. Doable, but you fight the tooling instead of using it.
Anything with components meant to outlive Tailwind itself. This is the one I think people underweight. Tailwind has had three major versions in five years. The migration from v2 to v3 was mostly fine. The jump to v4 (the new engine, the CSS-first config) is going to be a real chunk of work for anyone with a big v3 codebase. If I am building something I expect to maintain in 2031, I do not want my entire styling layer tied to a tool whose API has shifted twice in five years. Vanilla CSS, even verbose vanilla CSS, will still work in 2031.
The honest middle ground
Most of my client work in 2025 and 2026 has used Tailwind, because most of my client work has been web apps with constant churn and no in-house designer. So if you ask me “do you use Tailwind” the literal answer is yes, often.
But on the small handful of content-heavy sites I have built recently, including pivotlog, including a portfolio for a friend who is a photographer, and including a tiny documentation site for an even tinier open source project of mine, I went without. Just plain CSS. Maybe 200 lines. Sometimes SASS if I want variables and nesting, though honestly modern CSS does both natively now and I keep forgetting.
For the photographer’s site I think the entire stylesheet was about 140 lines. The HTML was unbelievably clean. <section class="gallery">, <figure class="shot">, <figcaption>. You could read the markup like prose. With Tailwind it would have read like a license plate.
The take, such as it is
Tailwind is a great hammer. Not everything is a nail. The rule I have settled on, roughly, is: if the design is going to change a lot and the markup is mostly UI chrome, Tailwind. If the design is going to be stable and the markup is mostly content, plain CSS.
And if you are a junior dev being told that Tailwind is the only way to write CSS in 2026, it is not. The people who told you that were trying to sell a course. Ignore them and write some p { line-height: 1.6; } sometimes. It is good for you.
If you want a broader poke at the dev toolchain question, I rambled about that in tips for web design and development a while back. Same disclaimer applies: this is just where I have landed, not where you have to.