Tailwind is a CSS framework where styles are applied through small utility classes rather than hand-written stylesheets. Its real value is that the available spacing, colours and type sizes come from your design tokens, so a developer in a hurry cannot invent a fourteenth shade of grey.
What is Tailwind?
Traditional CSS gives every developer a blank canvas and infinite options. That is fine for one person and a disaster for a team over two years: the spacing scale gradually becomes every number between 4 and 40, the palette acquires a dozen near-identical greys, and nobody can safely delete a rule because they cannot tell what uses it.
Tailwind inverts that. Styles are composed from a fixed set of utilities generated from a config file — your config file, holding your brand's spacing scale, colours and type steps. A developer writes p-6, not padding: 23px, because 23px is not in the system and there is no way to type it accidentally.
The build strips every utility the project does not use, so the shipped stylesheet contains only what the pages actually reference — usually a few kilobytes regardless of how large the codebase gets.
When we choose Tailwind
On any project with more than one developer and a design system worth protecting. The enforcement is the point: a design system documented in a PDF is a suggestion, and a design system compiled into the tooling is a constraint.
It is also the right call when the client will keep building screens after we hand over. A new page assembled from the same utilities looks like the rest of the site by default, without whoever built it having read the brand guidelines.
When we do not use Tailwind
When the design is genuinely bespoke per page rather than systematic — an editorial site where every article has its own art direction. Utilities fight that, and hand-written CSS expresses it better.
We also did not use it on this site. The RSX design system arrived as a hand-written token layer with its own component classes, and layering Tailwind on top would have duplicated the tokens and shipped a second reset. When a design system already exists and is coherent, adopting a framework to re-express it is work with no output.
What we build with Tailwind
Design systems compiled from your brand
Your spacing scale, palette, type steps and radii become the only values available. Every screen built afterwards is on-brand by construction, and a designer reviewing a new page has nothing to correct because nothing incorrect was possible.
Fast-moving marketing pages
Campaign landing pages that need to ship this week. Utilities let a page be assembled without writing new CSS, which means no new stylesheet to maintain after the campaign ends and nothing left behind to slow the site down.
Design systems that survive handover
Spacing, colour and type defined once as tokens, so a new page built by a different developer six months later still looks like the rest of the site. That consistency is the actual deliverable, not the utility classes.
RTL layouts without a second stylesheet
Tailwind's logical properties mirror the layout for Arabic automatically, so there is one stylesheet rather than two that drift apart. This site uses exactly that approach.
How we ship Tailwind projects
The config is generated from the brand tokens, not from Tailwind's defaults. Shipping with the stock palette means the site is styled like every other Tailwind site, which is the most common criticism of it and is entirely self-inflicted.
Arbitrary values — the escape hatch that lets you write any number inline — are flagged in review. Each one is a hole in the system, and a codebase full of them has the verbosity of utilities without the consistency.
What Tailwind costs you
The markup gets verbose. An element can carry a dozen classes, and people either stop noticing within a week or never make peace with it. It is a genuine aesthetic cost and worth seeing an example of before committing.
It also assumes a build step. A site that has to be editable by dropping HTML onto a server, with no tooling, cannot use it — the utilities are generated at build time and the stylesheet only contains what was present when the build ran.
There is a genuine learning cost for a developer who has never used it, roughly a week before it stops feeling backwards. And a designer reading the HTML will find it harder to follow than semantic class names.
It is also the wrong tool if you are building a component library that other teams will consume in their own applications. There, plain CSS with well-named classes travels better, because the consumer does not have to adopt your build setup to use your components.
Tailwind questions we get asked
Only if you ship its default palette and spacing, which is what most Tailwind sites do. We configure it from your brand tokens first, so the utilities available are your design system rather than the framework's. The framework is invisible in the result.
The markup is more verbose, yes. What you get back is that changing a style is a local edit with no risk of breaking a page elsewhere, and no growing stylesheet nobody dares delete from. On a team of more than one, that trade is worth making.
Small, because unused classes are removed at build time. Only what the site actually uses ships. The compiled stylesheet for this site is around 17kB compressed, which includes the full design system and both text directions.
Yes, and it coexists with existing CSS rather than requiring a rewrite. We usually introduce it on new sections first and leave working pages alone. Converting a whole site at once is rarely worth the regression risk unless the stylesheet is already unmanageable.