Hyvä’s choice of Tailwind as the styling foundation was the right call for the framework, and it is also the choice that catches teams off guard once a build needs to scale. A single-brand storefront with a small team can survive on raw utility classes. A brand portfolio running three to five websites on a single Adobe Commerce installation, or an agency template that needs to onboard new clients quickly, runs into the limits of unstructured Tailwind within months. The work of turning a pile of utility classes into a maintainable design system is real, and the patterns that hold up are not always the patterns that show up in the Tailwind docs.
This piece is for engineering teams running multi-brand or multi-storefront Hyvä builds. It covers the structural choices that keep CSS readable across many designers, many developers, and many years. Bemeir’s Hyvä practice has implemented these patterns across enterprise multi-brand portfolios, and the patterns below are the ones that have held up across team changes.
The Default Hyvä Tailwind Setup
A new Hyvä installation ships with a working Tailwind configuration: a `tailwind.config.js` at the theme root, a `@source` configuration pointing at the `.phtml` template files, and a baseline `tailwind.css` that includes Tailwind’s preflight and component layers. For a single-brand build with under fifty templates, this is fine.
The complications start when the same Adobe Commerce installation runs multiple brands. Each brand has its own visual identity, its own component variations, and its own design constraints. The default Hyvä setup expects a single Tailwind config per theme, and a brand portfolio with three brands needs three themes, each with its own config, each maintained separately. The duplication compounds fast.
Theme Inheritance for Brand Portfolios
The cleanest pattern is Adobe Commerce’s native theme inheritance. Build a parent theme that contains the shared structure, the layout templates, the base components, and the design tokens that all brands share. Each brand becomes a child theme that overrides only the templates and styles that diverge.
For Tailwind specifically, this means the parent theme owns the base `tailwind.config.js` with the shared utilities, plugins, and configuration. Each child theme extends or overrides specific configuration sections, colors, fonts, spacing scale, breakpoints, without rewriting the entire config. Hyvä’s theme inheritance documentation covers the mechanics, and the Tailwind preset documentation covers the JS-level pattern for inheriting and overriding configuration.
The output is a parent theme that contains 80% of the structure and child themes that contain only the brand-specific divergence. New brands are added by creating a new child theme, not by forking and modifying a complete theme. Bemeir’s Hyvä practice routinely runs this pattern for clients with multi-brand portfolios, and you can see the same patterns documented across the Bemeir Hyvä work.
Design Tokens as the Boundary
Within each theme, the boundary between “global design system” and “per-component styling” is the design token layer. Design tokens are the named values, colors, font sizes, spacing units, shadows, border radii, that the brand defines, and that templates reference indirectly rather than hard-coding.
In Tailwind, design tokens live in the `theme` section of the config. The pattern that scales is to define every meaningful design value as a token rather than allowing raw utility values to leak into templates. Instead of `text-[#1a2b3c]`, define `colors.brand.primary = ‘#1a2b3c’` and use `text-brand-primary`. Instead of `mt-[37px]`, expand the spacing scale to include a named value and use `mt-9`.
The discipline pays off when the brand evolves. Changing a primary color across a hundred templates is a one-line change if the templates all reference `text-brand-primary`. It is a hundred-template find-and-replace if the templates use raw hex values.
Component Layer Patterns
Tailwind’s component layer (`@layer components`) is where reusable component styles live. Use it carefully, overuse of the component layer recreates the problem that utility-first CSS was meant to solve. The right pattern is to put complex compositions in the component layer when they are reused across many templates, and to keep simple compositions inline as utility classes.
A useful test: if a composition uses more than four utility classes and appears in more than three templates, extract it to the component layer. If either condition is missing, leave it inline.
The component layer should also be organized by domain rather than by file. A single `components.css` with hundreds of unrelated components is hard to maintain. Split into files by domain: `buttons.css`, `cards.css`, `forms.css`, `navigation.css`. Each file is small and focused.
| Pattern | Use when | Avoid when |
|---|---|---|
| Raw utility classes inline | Simple, one-off styles | Composition used in many templates |
| Component layer abstraction | Reused composition across templates | One-time styling |
| Custom CSS in component CSS | Behaviors Tailwind can’t express | Anything achievable with utilities |
| Theme tokens | Brand-specific values | Values that change per page |
| Plugin definitions | Cross-cutting utilities (e.g., container queries) | One-off variants |
Plugin Strategy
Tailwind plugins extend the available utility classes. For Hyvä builds, a few plugins are nearly universal:
- `@tailwindcss/typography` for editorial content blocks
- `@tailwindcss/forms` for normalized form element styling
- `@tailwindcss/aspect-ratio` for responsive media containers (now native in newer Tailwind versions)
- `@tailwindcss/container-queries` for component-level responsive design
Custom plugins are appropriate when the team needs utility classes that the standard library does not provide and that recur across many templates. The pattern for writing them is well-documented in the Tailwind plugin reference.
Avoid one-off plugins for problems that should be solved with components. A plugin that adds a single highly-specific utility is usually a sign that the abstraction lives at the wrong level.
Purging and Production Builds
Tailwind’s JIT compiler produces a small CSS file by purging unused utilities at build time. For Hyvä builds, the configuration that matters is the content array, the list of files that Tailwind scans for utility class usage. Misconfigured content arrays produce one of two problems: bloated CSS (because Tailwind can’t tell what’s used) or missing classes (because Tailwind didn’t find them).
The right content array for a Hyvä theme includes:
- All `.phtml` template files in the theme
- All JavaScript files that reference Tailwind classes
- Any parent theme’s template files (for inheriting themes)
- Any module template files that override theme behavior
- Any third-party Hyvä-compatible modules that ship Tailwind class references
Verify the content array by building and checking the output CSS. Classes that are used in templates but missing from the output CSS indicate a content array gap.
Performance Considerations
Tailwind’s output CSS for Hyvä production builds is typically between 20kb and 60kb gzipped, depending on the breadth of utility usage. This is small enough that it should rarely need further optimization. Where optimization is warranted, the techniques include:
- More aggressive purging by reducing the variants generated for specific utilities
- Splitting CSS by page type (PLP, PDP, cart) and loading only what each page needs
- Critical CSS extraction for the above-the-fold content, with the rest deferred
For most stores, the default Tailwind purge produces CSS small enough that none of these techniques are necessary. Run PageSpeed Insights to confirm the CSS is not blocking critical rendering.
Dark Mode and Accessibility Variants
Hyvä stores increasingly include dark mode support, and Tailwind’s `dark:` variant supports this natively. Configure the dark mode strategy (class-based vs media-query based) in the theme config based on whether users get to choose or whether it follows system preference.
Accessibility variants, `prefers-reduced-motion`, `prefers-contrast`, `forced-colors`, should be considered alongside dark mode. The patterns are documented in the Tailwind variant reference, and the Web Content Accessibility Guidelines (WCAG) describe when each variant is required.
Multi-Storefront Inheritance Patterns
For Adobe Commerce installations with multiple storefronts that share a brand but differ in regional presentation (US vs EU, B2B vs DTC), the inheritance pattern goes one level deeper. The brand-level theme owns the design tokens and core components. Storefront-level themes override only the region-specific or channel-specific variants.
This pattern keeps the brand consistent across storefronts while allowing each storefront to evolve at its own pace. Bemeir’s enterprise builds use this pattern for clients with B2B Adobe Commerce instances running alongside DTC storefronts, and the same pattern applies to Shopify Plus multi-store deployments where Tailwind is the chosen styling layer.
The Discipline That Survives Team Changes
The thread connecting all of these patterns is that CSS architecture is a documentation problem disguised as a tooling problem. The team that writes utility classes inline today will rotate off the project in eighteen months, and the next team has to read the CSS and figure out the intent. Design tokens, component layer abstractions, plugin discipline, and content array configuration all make that future reading easier. Stores that invest in this structure produce CSS that ages well. Stores that don’t end up rebuilding the design system every two or three years, which is enormously expensive and almost always avoidable.
