Tailwind CSS
Tailwind CSS is how the interface is styled. Spacing, type, colour, and layout are utilities in the Nuxt components, with a small set of design tokens so a control on one screen matches the same control on the next. It is not a service we offer on its own. It is part of delivering an interface that a later team can continue to change.
This site is styled with Tailwind CSS.
Start a conversation about the product the interface belongs to, or read Project initiation.
At a glance
| Kind | CSS framework |
| Language | CSS, used from Vue components |
| Fits | Portals, administration, and public pages in the same product |
| Usually with | Nuxt |
When we use it
- A portal or administration interface that will gain screens over time, and needs those screens to remain visually consistent
- A design specific to the product, rather than a purchased theme with only the logo replaced
- Responsive layouts where the same component must work on a desktop and a tablet
- Server-rendered Laravel pages, when a flow does not justify a separate frontend
We do not use it to restyle a page builder, and we do not start a project by selecting a Tailwind CSS template.
What we rely on
- Tokens for colour, type, and radius, defined once and used throughout
- Components for controls that recur: fields, tables, empty states, and dialogs
- Responsive variants, so layout changes stay in the component rather than in a separate mobile stylesheet
- A rendered set of the common components, so a new screen is assembled from existing parts
Why it fits the work
- Faster screens after the first set. Later forms are built mostly from existing components. Time goes into the workflow, rather than into recreating spacing and layout.
- Consistency as more people work on it. Utilities are explicit. A later change is a class on the component, which is easier to review than a selector that affects a page the author was not changing.
- No additional runtime. The styling is delivered as CSS. It does not add a widget framework with its own upgrade cycle.
- Easier long-term maintenance. The design system is the code. There is no separate style-guide document that falls behind the interface.
How we build with it
The engagement follows Project initiation. Styling is part of the interface work, rather than a phase after the application exists.
- Architecture. Tokens and the initial components come from the screens in the first release, rather than from a brand system that does not match the product.
- Development. New interface work is built from those components. A one-off layout is used when a screen is genuinely unique.
- Hardening. Focus states, contrast, and target sizes are part of the component, including keyboard use. A control that works only with a pointer is incomplete.
- Release and support. Visual changes are released with the frontend. We do not maintain a second copy of the CSS outside the repository.
How it sits in the stack
Tailwind CSS is used in the Nuxt application, and in Laravel views that render HTML directly. It does not apply to Flutter, the Laravel API, or MySQL.
Cloudflare caches the built CSS with the other frontend assets.
In practice
The interfaces we deliver, including this site, use Tailwind CSS so additional screens can follow the same visual system. On a client portal, tables, filters, and forms should read as one system, because staff use them throughout the working day.
Questions
Will we be locked into Tailwind CSS?
The project will use whichever styling approach is chosen for it. Tailwind CSS produces ordinary CSS in a conventional frontend. A team that knows Vue can maintain it. Replacing it later has a similar cost to replacing any other design system that has spread through the components.
Can you match an existing brand?
Yes. Tokens take colour, type, and spacing from the brand the product must use. The work is to match the product, not to create a second identity. A prepared brand guide is helpful. It is not required before we start, which is the same standard described in Project initiation.
Do you design every screen in a separate tool first?
Not by default. Structure and the main screens are agreed before production interface work, often as a working interface rather than as a separate mock that is then rebuilt. Visual design still takes place. It takes place against the components the product will use.
Next step
If the interface is part of a platform you need built, or an existing one you need continued, start a conversation.
Related: Nuxt, Laravel, Technology.