Building a Scalable Design System with Tailwind, Blade, and Vue Components

You've probably been here: three months into a Laravel project and your views are a mess. Tailwind classes copy-pasted everywhere. Button markup duplicated in 47 different files. Your Vue components can't share styles with your server-rendered pages. It's frustrating.

Here's the thing. Building a proper design system with Tailwind CSS, Blade components, and Vue.js isn't just about keeping things tidy. It's about shipping features faster. On a recent client project, I spent two weeks refactoring the UI into a coherent design system. That investment paid off immediately. We cut feature development time by 40% because developers could grab pre-built components instead of reinventing buttons for the hundredth time.

In this guide, I'll show you how to build a design system that works across your entire Laravel application, from server-rendered Blade views to reactive Vue.js components. We'll cover Tailwind v4's CSS-first configuration, reusable components that share the same design language, dark mode, multi-tenant theming, and the common mistakes that'll trip you up.

Why You Need a Design System (Not Just a Component Library)

Let me clear this up first: a design system isn't just a folder of components.

A design system is your application's visual language codified into reusable patterns. It includes your color palette, typography scale, spacing system, component behaviors, and the actual code implementations. When done right, it becomes the single source of truth for how your application looks and behaves.

The difference matters. A component library gives you buttons and cards. A design system tells you which button to use, when to use it, and ensures it looks identical whether it's rendered by Blade or Vue.js. That consistency is what makes your app feel professional instead of cobbled together.

In my client projects, I've seen the impact firsthand. One e-commerce platform had 13 different button styles across their application. Not by design, but by inconsistency. After implementing a design system, their conversion rate increased by 8% because the UI became more predictable and trustworthy.

The Tailwind + Blade + Vue.js Architecture

So how do these three technologies work together?

Tailwind CSS provides your design tokens. Colors, spacing, typography, shadows. In Tailwind v4, these live directly in your CSS file using the @theme directive. No more JavaScript config files. This is your foundation.

Blade components handle server-rendered UI that doesn't need JavaScript. Navigation bars, footers, static cards, forms that work without JS. These components consume Tailwind utilities and provide a PHP-friendly API.

Vue.js components handle interactive, dynamic interfaces. Real-time dashboards, complex forms with validation, anything that needs reactivity. These components also use Tailwind utilities, ensuring visual consistency.

The magic happens when both Blade and Vue components share the same Tailwind configuration. Your primary color looks identical in a Blade button and a Vue button because they reference the same design token. And with Tailwind v4's CSS custom properties, those tokens are now accessible everywhere, including in JavaScript when you need them for charts or canvas rendering.

Setting Up Your Design System Foundation

Let's build this from scratch. I'm assuming you have Laravel 12 and Vue 3 installed with Vite. If you're on Laravel 11, everything still works, just check your Vite config.

Configure Tailwind v4 Design Tokens

Tailwind v4 is a fundamental shift. The tailwind.config.js file is gone. Your design tokens now live directly in your CSS file using the @theme directive, and content detection is automatic (no more content array). This is actually better for design systems because your tokens are pure CSS custom properties, accessible everywhere.

Here's how to set up your main CSS file:

/* resources/css/app.css */
@import "tailwindcss";

@theme {
  --color-primary-50: #f0f9ff;
  --color-primary-100: #e0f2fe;
  --color-primary-500: #0ea5e9;
  --color-primary-600: #0284c7;
  --color-primary-700: #0369a1;

  --color-secondary-500: #8b5cf6;
  --color-secondary-600: #7c3aed;

  --color-danger-500: #ef4444;
  --color-danger-600: #dc2626;

  --spacing-18: 4.5rem;
  --spacing-88: 22rem;

  --radius-xl: 1rem;
  --radius-2xl: 1.5rem;
}

That's it. No JavaScript config, no PostCSS setup, no content array. Tailwind v4 automatically detects your template files and generates only the CSS you use. The @theme directive creates CSS custom properties under the hood, so --color-primary-600 gives you bg-primary-600, text-primary-600, and so on.

This is a huge win for design systems. Your tokens are real CSS variables, which means you can reference them in JavaScript (getComputedStyle), in inline styles, and in third-party libraries without any build tooling.

Create Your Component Directory Structure

Organization matters more than you think. Here's the structure I use across all my projects:

resources/
├── css/
│   └── app.css          (Tailwind + @theme tokens)
├── views/
│   └── components/
│       ├── ui/
│       │   ├── button.blade.php
│       │   ├── card.blade.php
│       │   └── input.blade.php
│       ├── layouts/
│       │   ├── app.blade.php
│       │   └── auth.blade.php
│       └── features/
│           ├── user-profile.blade.php
│           └── project-card.blade.php
└── js/
    └── components/
        ├── ui/
        │   ├── Button.vue
        │   ├── Card.vue
        │   └── Input.vue
        └── features/
            ├── UserProfile.vue
            └── ProjectCard.vue

The ui/ folder contains primitive components: buttons, inputs, cards. These are your atoms. The features/ folder contains composed components that solve specific use cases. This separation prevents your UI components from accumulating business logic.

Building Reusable Blade Components

Let's create a button component that handles all our use cases. I spent way too long getting this right in my early projects, so I'll save you the headache.

The Base Button Component

<!-- resources/views/components/ui/button.blade.php -->
@props([
    'variant' => 'primary',
    'size' => 'md',
    'type' => 'button',
    'disabled' => false,
    'href' => null,
])

@php
$baseClasses = 'inline-flex items-center justify-center font-medium rounded-lg transition-colors duration-150 focus:outline-none focus:ring-2 focus:ring-offset-2 disabled:opacity-50 disabled:cursor-not-allowed';

$variantClasses = [
    'primary' => 'bg-primary-600 text-white hover:bg-primary-700 focus:ring-primary-500',
    'secondary' => 'bg-secondary-600 text-white hover:bg-secondary-700 focus:ring-secondary-500',
    'outline' => 'border-2 border-primary-600 text-primary-600 hover:bg-primary-50 focus:ring-primary-500',
    'ghost' => 'text-primary-600 hover:bg-primary-50 focus:ring-primary-500',
    'danger' => 'bg-danger-600 text-white hover:bg-danger-700 focus:ring-danger-500',
];

$sizeClasses = [
    'sm' => 'px-3 py-1.5 text-sm',
    'md' => 'px-4 py-2 text-base',
    'lg' => 'px-6 py-3 text-lg',
];

$classes = $baseClasses . ' ' . $variantClasses[$variant] . ' ' . $sizeClasses[$size];
@endphp

@if($href)
    <a href="{{ $href }}" {{ $attributes->merge(['class' => $classes]) }}>
        {{ $slot }}
    </a>
@else
    <button type="{{ $type }}" {{ $disabled ? 'disabled' : '' }} {{ $attributes->merge(['class' => $classes]) }}>
        {{ $slot }}
    </button>
@endif

This component handles buttons and links that look like buttons. I've seen developers create separate components for these. Don't. They're the same visual element with different underlying HTML.

Usage:

<x-ui.button>Save Changes</x-ui.button>
<x-ui.button variant="outline" size="lg">Cancel</x-ui.button>
<x-ui.button variant="danger" disabled>Delete Account</x-ui.button>
<x-ui.button href="/dashboard" variant="ghost">Go to Dashboard</x-ui.button>

Form Input Components with Validation

Forms are painful if you don't standardize them early. Here's an input component that handles labels, errors, and help text. It works automatically with Laravel's validation because error states bind through props:

<!-- resources/views/components/ui/input.blade.php -->
@props([
    'label' => null,
    'error' => null,
    'help' => null,
    'name' => null,
    'type' => 'text',
    'required' => false,
])

<div class="space-y-1">
    @if($label)
        <label for="{{ $name }}" class="block text-sm font-medium text-gray-700">
            {{ $label }}
            @if($required)
                <span class="text-danger-500">*</span>
            @endif
        </label>
    @endif

    <input
        type="{{ $type }}"
        name="{{ $name }}"
        id="{{ $name }}"
        {{ $required ? 'required' : '' }}
        {{ $attributes->merge([
            'class' => 'block w-full rounded-lg border-gray-300 shadow-sm focus:border-primary-500 focus:ring-primary-500 sm:text-sm ' .
                      ($error ? 'border-danger-500 focus:border-danger-500 focus:ring-danger-500' : '')
        ]) }}
    >

    @if($help)
        <p class="text-sm text-gray-500">{{ $help }}</p>
    @endif

    @if($error)
        <p class="text-sm text-danger-600">{{ $error }}</p>
    @endif
</div>

Use it in forms with automatic validation error binding:

<form action="/profile" method="POST">
    @csrf
    <x-ui.input
        name="email"
        label="Email Address"
        type="email"
        required
        :error="$errors->first('email')"
        help="We'll never share your email with anyone."
    />
    <x-ui.button type="submit" class="mt-4">Update Profile</x-ui.button>
</form>

I use this exact pattern for most client projects. If you want to validate the email format before submission on the client side, a quick check with a regex tester helps you craft the right pattern for your input component.

Building Vue.js Components That Match

Now let's create Vue components that look identical to our Blade components. The goal is that developers can switch between Blade and Vue without noticing visual differences.

The Vue Button Component

<!-- resources/js/components/ui/Button.vue -->
<script setup>
import { computed } from 'vue'

const props = defineProps({
  variant: {
    type: String,
    default: 'primary',
    validator: (v) => ['primary', 'secondary', 'outline', 'ghost', 'danger'].includes(v)
  },
  size: {
    type: String,
    default: 'md',
    validator: (v) => ['sm', 'md', 'lg'].includes(v)
  },
  disabled: Boolean,
  loading: Boolean,
  href: String,
  type: { type: String, default: 'button' }
})

const emit = defineEmits(['click'])

const variantClasses = {
  primary: 'bg-primary-600 text-white hover:bg-primary-700 focus:ring-primary-500',
  secondary: 'bg-secondary-600 text-white hover:bg-secondary-700 focus:ring-secondary-500',
  outline: 'border-2 border-primary-600 text-primary-600 hover:bg-primary-50 focus:ring-primary-500',
  ghost: 'text-primary-600 hover:bg-primary-50 focus:ring-primary-500',
  danger: 'bg-danger-600 text-white hover:bg-danger-700 focus:ring-danger-500',
}

const sizeClasses = { sm: 'px-3 py-1.5 text-sm', md: 'px-4 py-2 text-base', lg: 'px-6 py-3 text-lg' }

const buttonClasses = computed(() => [
  'inline-flex items-center justify-center font-medium rounded-lg transition-colors duration-150',
  'focus:outline-none focus:ring-2 focus:ring-offset-2 disabled:opacity-50 disabled:cursor-not-allowed',
  variantClasses[props.variant],
  sizeClasses[props.size],
])

const handleClick = (event) => {
  if (!props.disabled && !props.loading) emit('click', event)
}
</script>

<template>
  <component
    :is="href ? 'a' : 'button'"
    :href="href"
    :type="type"
    :disabled="disabled || loading"
    :class="buttonClasses"
    @click="handleClick"
  >
    <svg v-if="loading" class="animate-spin -ml-1 mr-2 h-4 w-4" fill="none" viewBox="0 0 24 24">
      <circle class="opacity-25" cx="12" cy="12" r="10" stroke="currentColor" stroke-width="4" />
      <path class="opacity-75" fill="currentColor" d="M4 12a8 8 0 018-8V0C5.373 0 0 5.373 0 12h4zm2 5.291A7.962 7.962 0 014 12H0c0 3.042 1.135 5.824 3 7.938l3-2.647z" />
    </svg>
    <slot />
  </component>
</template>

Notice the Tailwind classes are identical to the Blade version. That's intentional. Both components reference the same tokens, so they'll always look the same. The Vue version adds a loading prop with a spinner, which makes sense for async operations but isn't needed in server-rendered Blade buttons.

Sharing Design Tokens Between Blade and Vue

Here's where Tailwind v4 gives you a serious advantage over v3. Since your @theme tokens are CSS custom properties, they're accessible everywhere without any build-time workarounds.

Access Tokens in JavaScript

Need your primary color for a Chart.js chart or a canvas element? Just read the CSS variable:

// resources/js/composables/useDesignTokens.js
export function useDesignTokens() {
  const getToken = (name) => {
    return getComputedStyle(document.documentElement)
      .getPropertyValue(name).trim()
  }

  return {
    getColor: (name) => getToken(`--color-${name}`),
    getSpacing: (name) => getToken(`--spacing-${name}`),
    getRadius: (name) => getToken(`--radius-${name}`),
  }
}

Usage in a Vue component:

<script setup>
import { useDesignTokens } from '@/composables/useDesignTokens'

const { getColor } = useDesignTokens()
const chartColor = getColor('primary-600') // Returns '#0284c7'
</script>

In Tailwind v3, you'd have needed to export your config object and import it as JavaScript. With v4, the tokens are just CSS. No build step, no special imports, no breaking when you change your config. I covered how to use this approach for building full-stack apps with Vue 3 if you want the complete SPA setup.

Creating Compound Components

Simple buttons and inputs are great, but real applications need complex patterns. Let's build a modal that works in both Blade and Vue.

The Blade Modal (with Alpine.js)

<!-- resources/views/components/ui/modal.blade.php -->
@props([
    'show' => false,
    'maxWidth' => 'md',
])

@php
$maxWidthClasses = [
    'sm' => 'max-w-sm', 'md' => 'max-w-md',
    'lg' => 'max-w-lg', 'xl' => 'max-w-xl',
];
@endphp

<div
    x-data="{ show: @js($show) }"
    x-show="show"
    x-on:keydown.escape.window="show = false"
    style="display: none;"
    class="fixed inset-0 z-50 overflow-y-auto"
    role="dialog"
    aria-modal="true"
>
    <div
        x-show="show"
        x-transition:enter="ease-out duration-300"
        x-transition:enter-start="opacity-0"
        x-transition:enter-end="opacity-100"
        x-transition:leave="ease-in duration-200"
        x-transition:leave-start="opacity-100"
        x-transition:leave-end="opacity-0"
        class="fixed inset-0 bg-gray-500/75"
        @click="show = false"
    ></div>

    <div class="flex min-h-screen items-center justify-center p-4">
        <div
            x-show="show"
            x-transition:enter="ease-out duration-300"
            x-transition:enter-start="opacity-0 scale-95"
            x-transition:enter-end="opacity-100 scale-100"
            x-transition:leave="ease-in duration-200"
            x-transition:leave-start="opacity-100 scale-100"
            x-transition:leave-end="opacity-0 scale-95"
            {{ $attributes->merge(['class' => 'relative transform overflow-hidden rounded-xl bg-white shadow-xl ' . $maxWidthClasses[$maxWidth]]) }}
        >
            {{ $slot }}
        </div>
    </div>
</div>

This uses Alpine.js for interactivity, which keeps things lightweight. The modal handles escape key closing, backdrop clicks, and smooth transitions. If you're using Livewire instead, you can swap Alpine for Livewire's built-in modal support.

The Vue Modal

<!-- resources/js/components/ui/Modal.vue -->
<script setup>
import { watch, onUnmounted } from 'vue'

const props = defineProps({
  show: { type: Boolean, default: false },
  maxWidth: {
    type: String, default: 'md',
    validator: (v) => ['sm', 'md', 'lg', 'xl'].includes(v)
  }
})

const emit = defineEmits(['close'])
const maxWidthClasses = { sm: 'max-w-sm', md: 'max-w-md', lg: 'max-w-lg', xl: 'max-w-xl' }

const close = () => emit('close')
const handleEscape = (e) => { if (e.key === 'Escape' && props.show) close() }

watch(() => props.show, (val) => {
  if (val) {
    document.addEventListener('keydown', handleEscape)
    document.body.style.overflow = 'hidden'
  } else {
    document.removeEventListener('keydown', handleEscape)
    document.body.style.overflow = ''
  }
})

onUnmounted(() => {
  document.removeEventListener('keydown', handleEscape)
  document.body.style.overflow = ''
})
</script>

<template>
  <Teleport to="body">
    <Transition enter-active-class="ease-out duration-300" enter-from-class="opacity-0" enter-to-class="opacity-100"
                leave-active-class="ease-in duration-200" leave-from-class="opacity-100" leave-to-class="opacity-0">
      <div v-if="show" class="fixed inset-0 z-50 overflow-y-auto">
        <div class="fixed inset-0 bg-gray-500/75" @click="close" />
        <div class="flex min-h-screen items-center justify-center p-4">
          <div :class="['relative transform overflow-hidden rounded-xl bg-white shadow-xl', maxWidthClasses[maxWidth]]" @click.stop>
            <slot :close="close" />
          </div>
        </div>
      </div>
    </Transition>
  </Teleport>
</template>

The Vue version uses Teleport to render outside the component hierarchy (preventing z-index issues) and properly cleans up event listeners to avoid memory leaks. Same visual result, different interactivity model.

Dark Mode: Get It Right from Day One

If dark mode is on your roadmap, add support from the start. Retrofitting is painful. I added dark mode to a client project three months after launch and it took a full week to update every component. Don't repeat that mistake.

Tailwind v4 handles dark mode differently than v3. The old darkMode: 'class' config key is gone. By default, dark mode uses the prefers-color-scheme media query. If you want manual toggle support (which most apps need), add a custom variant in your CSS:

/* resources/css/app.css */
@import "tailwindcss";
@custom-variant dark (&:where(.dark, .dark *));

@theme {
  --color-primary-600: #0284c7;
  /* ... rest of tokens */
}

That single @custom-variant line replaces the entire JavaScript config key. Now toggle the .dark class on your <html> element, and all dark: utilities work as expected:

<button class="bg-white text-gray-900 dark:bg-gray-800 dark:text-white">
    Toggle Me
</button>

For a more sophisticated approach in multi-tenant apps, define your colors as CSS variables in @layer base and switch them based on theme class. This way, you don't need dark: on every element:

@layer base {
  :root {
    --surface: #ffffff;
    --text: #111827;
  }
  .dark {
    --surface: #1f2937;
    --text: #f9fafb;
  }
}

@theme {
  --color-surface: var(--surface);
  --color-text: var(--text);
}

Then your components just use bg-surface text-text and the theme switch happens automatically. Zero dark: prefixes needed. This is the approach I use in SaaS applications with Filament where each tenant can have their own branding.

Dynamic Theming for Multi-Tenant Apps

Sometimes you need multiple themes in one application. Multi-tenant SaaS is the most common case, where each client gets their own brand colors without rebuilding the application.

With Tailwind v4's CSS custom properties, this is surprisingly simple:

<!-- In your layout Blade template -->
<style>
    :root {
        --color-primary-500: {{ $tenant->primary_color ?? '#0ea5e9' }};
        --color-primary-600: {{ $tenant->primary_dark ?? '#0284c7' }};
    }
</style>

Because your @theme tokens are CSS variables, overriding them at runtime instantly changes every component that references them. No rebuild needed. I implemented this pattern for a white-label SaaS last year, and each client got their logo and brand colors with zero code changes on the frontend.

For the Vue side, create a composable that loads theme data:

// resources/js/composables/useTheme.js
import { ref } from 'vue'

const currentTheme = ref(null)

export function useTheme() {
  const loadTheme = async (tenantId) => {
    const { data } = await fetch(`/api/themes/${tenantId}`)
    currentTheme.value = data

    // Apply to CSS custom properties
    Object.entries(data.colors).forEach(([key, value]) => {
      document.documentElement.style.setProperty(`--color-${key}`, value)
    })
  }

  return { currentTheme, loadTheme }
}

Performance: Keeping Your Build Lean

A design system affects your build size. Tailwind v4's new engine helps enormously (5x faster full builds, 100x faster incremental builds), but you still need to watch a few things.

Automatic CSS Purging

Tailwind v4 automatically detects your template files by scanning your project and respecting .gitignore. No content array to maintain. But watch out for dynamic class names:

// BAD: Tailwind can't detect this
$class = "bg-{$color}-600";

// GOOD: Use complete class names
$variantClasses = [
    'primary' => 'bg-primary-600',
    'danger' => 'bg-danger-600',
];

If you dynamically construct class names from strings, Tailwind won't find them during its scan. Always use complete, static class strings. This applies to both Blade and Vue.

Code Split Your Vue Components

Don't load every component upfront. Use dynamic imports in your app.js:

// resources/js/app.js
import { createApp } from 'vue'

const app = createApp({})

// Lazy-load heavy components
app.component('Modal', () => import('./components/ui/Modal.vue'))
app.component('DataTable', () => import('./components/features/DataTable.vue'))

app.mount('#app')

Better yet, use route-based code splitting if you're building an SPA with Inertia. Components load only when their route is visited.

Monitor Bundle Size

Vite has built-in bundle analysis. Add visualization to spot bloat:

npm install --save-dev rollup-plugin-visualizer

Then configure it in your vite.config.js and run npm run build. I do this before major releases to catch unused dependencies. Last month I found an unused icon library adding 200KB to a client's bundle. Gone in one line.

Common Mistakes and How to Avoid Them

Let me share the mistakes I've made so you don't have to.

Mistake 1: Over-Engineering Early

I once spent three weeks building a perfect design system for a project that pivoted two months later. Build what you need now, not what you might need. Start with 5-7 core components: Button, Input, Card, Modal, Alert. Add more as patterns emerge from actual development. If you need a component three times, extract it. Before that, keep it inline.

Mistake 2: Ignoring Accessibility

I've seen beautiful design systems that are unusable with keyboards. Use semantic HTML. Add ARIA labels when necessary. Test with keyboard navigation. Your design system sets the accessibility baseline for your entire application.

<!-- Bad -->
<div @click="handleClick">Click me</div>

<!-- Good -->
<button @click="handleClick" type="button">Click me</button>

Mistake 3: Inconsistent Naming

Pick a naming pattern and stick to it. Blade components: kebab-case (<x-ui.button>). Vue components: PascalCase files (Button.vue). Props: camelCase in both. CSS classes: Tailwind utilities only. Consistency makes your codebase predictable. New developers can guess where files live and how components are named without checking docs.

Mistake 4: Not Version Controlling Design Tokens

Treat your design tokens like a database schema. When you change primary-600 from blue to purple, every component using that token updates automatically. That's powerful but dangerous. Document changes in a DESIGN_SYSTEM.md changelog with semantic versioning. When someone asks "why did this button change?", you have an answer.

Documentation and Component Discovery

A design system is useless if developers don't know what components exist. I learned this when teammates kept building custom buttons instead of using the design system.

Build a simple showcase page that displays all your components with usage examples and mount it at /design-system in development. It becomes your living documentation. For Vue components specifically, Storybook is the gold standard for interactive browsing and testing.

The documentation doesn't need to be fancy. A single Blade page with every component variant rendered side-by-side, plus the code to use it, is worth more than a 50-page PDF that nobody reads. Focus on making components discoverable, not on writing exhaustive docs. I follow similar design pattern principles on the backend to keep code organized and discoverable.

Frequently Asked Questions

Should I use Blade components, Vue components, or both?

Use both. Blade for server-rendered content that doesn't need JavaScript (nav, footer, static pages, forms), and Vue for anything interactive (dashboards, live search, complex multi-step forms). The key is sharing the same Tailwind tokens so they look identical. Most Laravel apps are 70% Blade and 30% Vue, unless you're building a full SPA with Inertia and Vue 3.

How do I migrate my design system from Tailwind v3 to v4?

Run npx @tailwindcss/upgrade in your project root. It handles about 90% of changes automatically: renaming utilities, updating imports, and converting your config. Then move your tailwind.config.js theme values into @theme blocks in your CSS, replace darkMode: 'class' with @custom-variant dark, and remove the content array (detection is now automatic). Review the diff manually before committing.

What's the best way to handle responsive variants in a design system?

Don't bake responsive breakpoints into your components. Let the consumer decide. Your Button component should accept a size prop, but the page layout should control whether it's size="sm" on mobile via conditional rendering or responsive Tailwind classes. Keep components dumb about viewport size. Layout components handle responsiveness.

How do I test my design system components?

For Blade components, use Laravel's built-in view testing to assert rendered markup. For Vue components, use Vitest with Vue Test Utils to test props, events, and rendered output. Visual regression testing with tools like Percy or Chromatic catches unintended style changes across your entire component library. I run Lighthouse audits periodically to ensure accessibility scores stay above 90.

Can I share a design system across multiple Laravel projects?

Yes. Extract your components into a private Composer package (for Blade) and an npm package (for Vue). Publish your Tailwind @theme tokens as a separate CSS file that each project imports. This is the approach agencies use when they have 5+ projects sharing the same brand. Version it properly so projects can upgrade independently.

Wrapping Up

A well-designed design system transforms how you build features. What used to take days now takes hours. Consistency becomes automatic instead of aspirational.

The key is starting simple and evolving gradually. You don't need 50 components on day one. Build the foundation with buttons, inputs, cards, and modals, then expand as patterns emerge. And with Tailwind v4's CSS-first approach, your design tokens are more portable and powerful than ever. They work in Blade, Vue, plain JavaScript, and even external tools that read CSS variables.

Remember: your design system exists to make developers productive, not to enforce rules for the sake of rules. If a component isn't useful, delete it. If developers keep writing custom CSS, understand why and fix the gap.

Need help implementing a design system for your Laravel application? I've built scalable component libraries for SaaS products, admin dashboards, and marketing sites. Let's talk about your project.