Tailwind CSS

Why can nobody safely change the CSS on your site after a few months?

I build frontends in Tailwind CSS: a design system in configuration, consistent components and styling you can change without fearing that another page falls apart. It works with Sage themes, Alpine and React.

Discuss the frontend Back to the home page

Traditional CSS on a website ages in a peculiar way. The first file is tidy, a year later it has three thousand lines, four classes for the same button and a handful of important overrides someone added to beat the previous override. Nobody knows which rules are still in use, so nothing gets deleted and the file keeps growing. A change that sounds like fifteen minutes of work then means an hour of checking whether something broke somewhere else.

Tailwind CSS solves this by keeping styling next to the component. Instead of inventing class names and maintaining a parallel stylesheet, the appearance is written right at the element using small utility classes. The values are not arbitrary: colours, spacing, font sizes and radii are defined in the project configuration and act as a design system. Only the classes actually used end up in the final CSS, so the file barely grows as pages are added.

Why styling belongs next to the element it describes

The biggest practical benefit is not in writing, it is in deleting. When you delete a component its appearance goes with it, because no orphaned block of CSS is left behind that nobody dares to remove. A change to a button on one page cannot leak onto another, because there is no global rule connecting them. Readability is kept by extracting repeated elements into components in the template. The result is a frontend where change is predictable and does not require archaeology in old stylesheets.

Deleting a component deletes its CSS with it
No global rules fighting each other with overrides
Every change has a visible, contained reach
Repetition is solved with a component, not copy-paste

A design system in configuration, not in someone's head

The project configuration defines the colour palette, the spacing scale, typography, radii and shadows. From that point the project has a single source of truth for appearance, and it becomes impossible for a fifth page to grow a shade of blue slightly different from the brand one. If the brand identity changes, the configuration is updated and the change flows through the whole site. The same tokens can drive dark mode and component states, so the design is a real system rather than a folder of pictures.

Colours, spacing and typography in one place
No stray shades or one-off dimensions
A brand change propagates across the whole site
Ready for dark mode and component states

Consistent components across every page

From the design system I build the component set the site actually uses: buttons in their variants, form fields with error states, cards, tables, alerts, navigation and the footer. A new page is then assembled from finished parts and no new button style appears with every request. That shows up directly in the price, because most edits become a matter of using an existing component rather than drawing one from scratch. It also makes handover clear about what is a building block and what is a one-off exception.

Buttons, fields, cards and alerts in one set
New pages are assembled, not redrawn
Error, loading and empty states thought through
Fewer hours on every subsequent request

Tailwind with Sage, Alpine and React

Tailwind is not tied to one framework, which matters on a long-lived project. In a WordPress theme on Sage it is written directly in Blade components, with Alpine the classes are toggled by element state, and in a React application it works the same way. If the project ever moves off WordPress to another platform, the design system and most of the markup move with it. That avoids a dependency on a single supplier or a single tool, which is a more common frontend problem than people expect.

Blade components in Sage themes
Classes toggled by state through AlpineJS
The same syntax in React applications
The design system survives a platform change

Performance, CSS size and cost

At build time only the classes genuinely used in the project end up in the final file. A typical site therefore ships CSS measured in tens of kilobytes instead of hundreds, which shows directly in Core Web Vitals and in how the site behaves on a mobile connection. The difference is most visible on sites that previously ran on a general-purpose theme loading styles for every possible feature. I work at 40 EUR per hour including VAT, and preparing a design system with a base component set is usually 8 to 20 hours.

Only the classes in use reach the final CSS
Tens of kilobytes instead of hundreds
A measurable effect on Core Web Vitals
A design system roughly 8 to 20 hours at 40 EUR per hour including VAT

Frequently asked questions about Tailwind CSS

Is HTML full of classes not hard to read?

It looks unusual at first, but repeated elements are extracted into components, so a long list of classes lives in one place in the project. In exchange you can see at every element exactly how it looks without jumping between a template and a stylesheet.

Can Tailwind be introduced on an existing site?

It can, and gradually. Tailwind runs alongside the original CSS and new sections are written in it. I only recommend a full swap when the design is being reworked anyway, otherwise the old and new layers overlap for no good reason.

Can an editor still update content on such a site?

Yes. Tailwind concerns templates, not content. Editors work in the WordPress admin or CMS exactly as before and change text, images or the order of sections without touching any code.

Is Tailwind a good fit for an e-shop?

It is, and often it pays off most there. A shop has many repeated elements such as product cards, filters, cart and checkout that all need to look the same. A design system keeps them consistent across hundreds of product pages.

What does preparing a design system cost?

A base set with palette, typography and components typically lands between 8 and 20 hours, which is 320 to 800 EUR including VAT at a rate of 40 EUR per hour. Scope is driven by the number of components, dark mode and how many variants each has.

Want a frontend where changes are not scary?

Tell me what the site runs on and whether you already have a design or brand guidelines. I will propose the scope of the design system and the components that are genuinely worth building.

Discuss the frontend