What we do with Tailwind
Tailwind styles elements with small single-purpose classes in the markup instead of a separate stylesheet full of names somebody invented at 11pm. The practical effect is that you can see what an element looks like while you are looking at the element, and deleting a component deletes its styles with it.
Tailwind 4 moved configuration into CSS itself. Your brand colors, type scale, and spacing are declared once as CSS variables and used everywhere, which means a design token change is one edit rather than a search across a codebase.
Design systems in code
We translate a brand into tokens for color, type, spacing, and radius, then build components on top of them, so the site stays consistent as other people add pages.
Component layers, not copy and paste
Utilities belong inside components, partials, or sections. Without that discipline you get the same fourteen classes repeated in nine files and a redesign that touches every one of them.
Accessible custom interfaces
Tailwind gives you no components, which means keyboard support, focus states, and announcements are yours to get right. We build and test those rather than assuming a class name handled it.
Retrofits and migrations
Moving an older front end onto Tailwind incrementally, usually one section at a time, so you never have a period where the site is half rebuilt and fully broken.
When Tailwind is the right call, and when it is not
Good fit: a custom design you want to hold
When the layout is specific to you, Tailwind gets out of the way. There is no framework opinion to override, and the stylesheet stays small because unused utilities are never generated.
Good fit: a codebase more than one person touches
Styles live with the markup they belong to, so a new developer does not have to guess whether removing a class breaks a page somewhere else.
Watch out: you get no components
Bootstrap hands you a tested modal and dropdown. Tailwind hands you nothing, so somebody has to build those and get the accessibility right. Budget for it or use a headless component library.
Watch out: noisy markup without discipline
Long class strings are the standard complaint and they are only a real problem when there is no component layer. If your content lives in a system where editors paste raw HTML, that discipline is hard to enforce.
Watch out: a build step is required
Tailwind needs a build process. On a platform where you can only inject CSS into a template, that is a poor fit and plain CSS is the honest answer.
Questions we get about this
- Why do you use Tailwind instead of Bootstrap?
-
Because most of our work is custom design, and Tailwind has no built-in look to override. Your brand becomes a set of tokens for color, type, and spacing, and every component uses them, so the site stays consistent as it grows.
Bootstrap is still the better answer for internal tools and admin panels, where tested components matter more than distinctiveness. We keep both in the toolkit and pick based on what the project needs.
- Can my team update the site after launch?
-
Yes. We build on a CMS your team can manage, and structure the design so new pages can reuse what already exists.
- Will it be accessible?
-
Yes. We build to WCAG standards on every project. If you have specific compliance requirements, tell us upfront and we'll scope accordingly.
- Will you maintain a site you didn't build?
-
Yes, often. Our retainer practice started largely with sites built by other teams. We'll do a short technical and accessibility audit before the retainer starts so we both know what we're working with.
Planning a front-end rebuild?
Bring the design, the codebase, or both. A free consultation will tell you whether an incremental move onto Tailwind makes sense or whether what you have is worth keeping.