Real World Tailwind CSS: Controlling the Special Cases (Part 2/2)

So in the last article, we have discussed the best practices for using Tailwind CSS4 in the real world - which is,

A dedicated team maintaining the components
The other teams just use them for creating pages
Linter to enforce boundaries, not good will

In this way we "hide" the long utility class strings from rest of the codebase.

Special Landing Page

What happens when marketing launches a new campaign and needs a gradient CTA button that deviates from the core design system??

The obvious choice might be to do something like this:

const variants = {
  primary: "...",
  secondary: "...",
  // The new marketing variant
  "ai-campaign": "bg-gradient-to-r from-emerald-500 to-teal-500 animate-pulse text-lg px-8 py-4" 
};

This looks clean today. But in a few years, it might grow to

<Button
  variant="primary"
  isMarketing
  isAnimated
  hasGlowEffect
  showConfetti
  campaignTheme="black-friday-2024"
  seasonalBadge="sale"
  size="xl"
/>

Now it's bloated again... this is called prop explosion.

What's the Best Way?

Option 1: Keep It Local with Tailwind Utilities

Sometimes a design is so specific that it's hard to imagine anyone using it again. So, just make the page live in a separate directory and use utility classes directory

////  Inside @/app/marketing/campaign/page.tsx ////
...
export default function CampaignPage() {
  return (
    <div>
      <h1>The Next Generation of AI</h1>

      {/* Custom, one-off visual classes are localized entirely to this page */}
      <Button
        className={cn("bg-indigo-600 text-white px-4 py-2", className)} >
        Get Early Access
      </Button>
    </div>
  );
}

Once the campaign ends, just delete the page. The component is left untouched.

Option 2: Add a Variant

If there are only a handful of visual styles and they genuinely represent something the business uses repeatedly, I'd probably just add another variant.

<Button variant="primary" />
<Button variant="secondary" />
<Button variant="cta" />
<Button variant="voucher" />

The props felt easy enough to understand, and it keeps the page code nice and clean. In a smaller codebase, maintaining a few extra variants would not be a big deal.

Option 3: Create a Specialized Component

There's also a middle ground. If I find myself copying the same styling around a campaign or a particular section of the application, I'd probably start wondering whether it's worth creating something like a .


function CampaignButton({ className, ...props }) {
  return (
    <Button
      className={cn(
        "bg-gradient-to-r ...",
        className
      )}
      {...props}
    />
  );
}

// Base component
<Button>
  Testimonials
</Button>

// Campaign-specific component
<CampaignButton>
  Get Early Access
</CampaignButton>

That way the shared Button stays focused on being a button, while the campaign gets its own reusable abstraction. It feels like a reasonable compromise when you're not quite ready to promote something into the design system, but you don't want duplicated styling everywhere either.

The goal is: