A story about convenience, creative suffocation, and 90+ files of regex carnage.

Were building a peer-to-peer rental marketplace with Phoenix LiveView. DaisyUI made the early days fast. The components looked "good enough." Dark mode worked out of the box.

And then we stopped moving fast.

The Honeymoon

DaisyUI is a Tailwind CSS component library. You slap btn btn-primary on a button and it looks like a button. card gives you a card. modal-box gives you a modal.

For prototyping? Genuinely great.

We picked it because we were a small team building in Elixir/Phoenix. Spending weeks hand-styling every badge, dropdown, and tab group wasnt how we wanted to spend our time. DaisyUI let us focus on the product.

That was the pitch anyway.

The Resentment

Heres what actually happened over the next few months.

Everything looked the same. Our homepage looked like every other DaisyUI site. Our admin dashboard looked like a template. Item cards, booking flow, messaging inbox. All had that unmistakable "I used a component library" aesthetic.

You know the look. Rounded corners just so. That specific shade of primary blue. The badge that screams "I'm a default."

We werent building a SaaS dashboard. We were building a marketplace where people rent real things to real people. It needed personality. It needed to feel like our product. Not a themed Bootstrap clone wearing a Tailwind costume.

Customization meant fighting the framework. Want to change how a badge looks? You're overriding DaisyUI styles. Want a button with a slightly different hover state? Wrestling specificity. Want to add an opacity variant to a semantic color? Good luck. DaisyUI's color system doesnt expose that cleanly.

We were spending more time undoing DaisyUI's opinions than we would have spent writing styles from scratch.

The invisible styles were the worst part. DaisyUI applies styles through component classes like table, card, form-control. When they work, you dont notice them.

When you remove DaisyUI? You discover that your tables had no padding. DaisyUI's .table was providing it. Your cards had no border-radius. The .card class was doing that. Your form layouts collapse because .form-control was adding spacing you didnt know about.

You dont realize how much a component library is doing for you until you take it away. And you dont realize how much its doing to you until you try to do something different.

The Decision

Breaking point was a design review. We looked at our site next to three other DaisyUI projects.

They were indistinguishable. Different colors, same soul.

We wanted creative control. Full, unapologetic control over every pixel. No framework opinions between us and our design.

We wanted predictable dark mode. Write dark:bg-stone-900 and know exactly what would happen. No variable indirection. No theme system surprises.

We wanted transparency. When you read bg-emerald-600 hover:bg-emerald-700 text-white rounded-lg px-4 py-2, you know exactly what that button looks like. When you read btn btn-primary, you have to go check what DaisyUI decided that means this week.

So we made the call. Rip it all out. Every DaisyUI class, every themed variable, every implicit style. Replace it with plain Tailwind CSS. Every color explicit. Every dark mode variant spelled out.

90+ files. 4000+ lines changed.

The Migration

Step 1. Plan and Audit

Before touching a single file, we catalogued every DaisyUI class in the codebase and mapped it to a Tailwind replacement.

We wrote a 1,113-line plan document. 13 tasks. 70+ files identified. Every DaisyUI class got a row in a mapping table.

DaisyUI Class	Tailwind Replacement
`btn btn-primary`	`bg-primary hover:opacity-90 text-primary-content rounded-lg px-4 py-2 font-medium`
`badge badge-success`	`inline-flex items-center rounded-full px-2.5 py-1 text-xs bg-success/10 text-success font-medium`
`card`	`rounded-xl` plus whatever the card actually needed
`card-body`	`p-6`
`modal-box`	`bg-surface-overlay rounded-2xl shadow-xl`
`form-control`	`space-y-1.5`
`table`	explicit `px-4 py-3` on every `<th>` and `<td>`
`label-text-alt`	`text-xs text-text-muted`
`link link-primary`	`text-primary hover:underline`

This mapping was the single most important artifact of the migration. Without it we would have been guessing.

Step 2. Remove DaisyUI Package and Imports

The clean break.

Deleted assets/vendor/daisyui.js and assets/vendor/daisyui-theme.js. Removed DaisyUI plugin imports from assets/css/app.css. Removed DaisyUI from the Tailwind build config.

At this point the site looked like a newspaper from 1997. Every implicit style DaisyUI was providing vanished. Tables collapsed. Buttons became plain text. Modals lost their backgrounds.

This was expected. This was the point of no return.

Step 3. Build an Intermediate CSS Variable System

We didnt go straight to plain Tailwind colors. First we built a bridge. A custom CSS variable system that would let us keep writing semantic class names like bg-primary and text-surface while we transitioned.

:root {
  --color-primary: #2d6a4f;
  --color-primary-content: #ffffff;
  --color-surface: #faf8f5;
  --color-surface-raised: #ffffff;
  --color-surface-sunken: #f0ece4;
  --color-text: #1a1a1a;
  --color-text-secondary: #6b7280;
  --color-border: #e5e0d8;
  --color-success: #16a34a;
  --color-warning: #f59e0b;
  --color-error: #dc2626;
  --color-info: #3b82f6;
}

[data-theme="dark"] {
  --color-primary: #4ade80;
  --color-surface: #1c1917;
  --color-text: #f5f5f4;
  /* ... */
}

This was a stepping stone. Not the destination. More on that later.

Step 4. Wire Variables to Tailwind 4.x

Tailwind 4 introduced the @theme directive. We used it to map our CSS variables to utility classes.

@theme {
  --color-primary: var(--color-primary);
  --color-surface: var(--color-surface);
  --color-text: var(--color-text);
  /* This enabled bg-primary, text-surface, etc. as Tailwind utilities */
}

Now we could write bg-primary in templates and it would resolve to our CSS variable, which would resolve to the right color for the current theme.

Clever? Yes. Sustainable? Keep reading.

Step 5. Bulk Conversion with Parallel Agents

This was the grunt work. We used Claude Code to launch 6 parallel agents, each handling a group of files.

Agent 1 got domain components. Seller avatar, chat bubble, item form. Agent 2 got UI components plus admin pages. Agent 3 got static pages. How it works, safety, contact, about. Agent 4 did a fixup pass on partially-converted files. Agents 5 and 6 handled remaining domain and admin files.

Each agent applied the class mapping reference to every template in its file group. Between batches we ran mix compile --warnings-as-errors to catch breakage immediately.

Step 6. The Grep Audit

After the bulk pass we grepped for every known DaisyUI class pattern.

grep -rn "btn-primary\|badge-success\|card-body\|modal-box\|form-control\|label-text\|link-primary" lib/

Found 10 remaining instances across 3 files. Fixed manually.

Step 7. The Ghost Hunt

This is the step most migration guides skip.

After removing DaisyUI, some of its classes become no-ops. They sit in your HTML doing absolutely nothing because the CSS that powered them is gone. They dont cause errors. They dont show up in grep searches for "broken" things. They just silently make your markup dishonest.

We found the card class in 42 instances across 9 files. Replaced with rounded-xl or removed entirely. Found avatar class in 1 file. Removed. Found duplicate padding. Elements with both px-1.5 py-0.5 AND px-2 py-2. The DaisyUI class used to win via specificity, leaving the Tailwind class as dead code. Consolidated. Found missing table padding. Every <th> and <td> needed explicit px-4 py-3 because DaisyUI's .table had been silently providing it.

Step 8. Visual Testing with Playwright

We used Playwright to screenshot 13+ pages in both light and dark mode. Homepage, Browse, Registration, Onboarding, How It Works, About, Contact, My Listings, Item Detail, Mobile viewports.

This caught two issues.

Dark mode propagation failure. The navbar respected the theme but content areas didnt. Black text on dark backgrounds.

The "square boxes" issue. My Listings page had badges and table cells with no padding. Everything looked cramped and broken.

Both were consequences of invisible DaisyUI styles wed been relying on without knowing it.

Step 9. The Second Migration

Heres the twist nobody plans for.

Our intermediate CSS variable system had its own problems.

The custom tokens like bg-surface-sunken, text-text-secondary, border-border-strong were better than DaisyUI. But they introduced a new layer of indirection. Dark mode bugs persisted because the variable system was doing the theme switching. When something went wrong we were debugging CSS custom property cascading instead of just looking at the class name and knowing the color.

So we did it again. We wrote Perl scripts. Yes, Perl. s/pattern/replacement/g is unbeatable for bulk regex across files. Ran 6 passes over the codebase.

bg-surface-sunken  →  bg-stone-100 dark:bg-stone-900
bg-surface-raised  →  bg-white dark:bg-stone-800
text-text-secondary →  text-stone-500 dark:text-stone-400
border-border      →  border-stone-200 dark:border-stone-700
bg-primary         →  bg-emerald-600 dark:bg-emerald-500
text-error         →  text-red-500 dark:text-red-400

The Perl scripts handled opacity variants with regex capture groups.

s/bg-surface-sunken\/(\d+)/bg-stone-100\/$1 dark:bg-stone-900\/$1/g;

6 passes because each pass revealed tokens wed missed. Opacity variants, gradient prefixes like from-, via-, to-, focus/hover pseudo-class combinations, ring-offset colors. Each pass was more targeted based on what grep showed was still remaining.

We also had to manually fix 5 files where colors were dynamically interpolated in Elixir.

# Before. Dynamic interpolation that cant be statically replaced
"bg-#{@config.color}/10"

# After. Explicit class passed as an assign
@config.bg_light_class  # "bg-emerald-600/10 dark:bg-emerald-500/10"

Step 10. Final Verification

mix format clean. mix compile --warnings-as-errors zero warnings. mix credo zero issues. mix test 845 tests, 0 failures after updating 3 tests that asserted old class names. grep for any remaining token, zero matches.

90 files changed. 3,995 insertions. 2,610 deletions.

The Color System We Landed On

No variables. No tokens. No indirection. Just Tailwind colors with explicit dark variants.

Role	Light	Dark
Backgrounds	`stone-50`, `stone-100`, `white`	`stone-900`, `stone-800`
Text	`stone-800`, `stone-500`, `stone-400`	`stone-100`, `stone-400`, `stone-500`
Borders	`stone-200`, `stone-300`	`stone-700`, `stone-600`
Primary	`emerald-600`	`emerald-500`
Success	`teal-600`	`teal-500`
Error	`red-500`	`red-400`
Warning	`amber-500`	`amber-400`
Info	`blue-500`	`blue-400`
Accent	`orange-500`	`orange-400`

Is it more verbose? Yes. bg-emerald-600 dark:bg-emerald-500 hover:bg-emerald-700 dark:hover:bg-emerald-400 text-white rounded-lg px-4 py-2 font-medium is longer than btn btn-primary.

But when something looks wrong you read the class list and you know what it should look like. No layer of abstraction to dig through. No "what does this variable resolve to in dark mode on this specific element?" debugging.

The truth is right there in the markup.

What We Learned

Component libraries are design debt. They get you to v1 fast. But every week after that youre paying interest in the form of overrides, specificity battles, and a site that looks like everyone elses.

Intermediate abstractions have intermediate problems. Our CSS variable system was better than DaisyUI but still hid the truth. Two migrations could have been one if wed gone straight to plain Tailwind.

Invisible styles are the hardest to migrate away from. DaisyUI's .table silently adding cell padding. .card providing border-radius. .form-control adding spacing. These are the things that break your site in ways that dont trigger compiler errors.

Perl is still the king of bulk text transformation. We used perl -pi -e 's/old/new/g' to process 90 files across 6 passes. Python, sed, and IDE find-and-replace all fall short when you need regex capture groups with dynamic replacement strings across an entire codebase. The tool is 38 years old and still unmatched for this specific job.

Grep is your migration's safety net. After every pass, grep -rn for the patterns you replaced. Then grep again for patterns you might have missed. Then grep one more time for the ghost classes that are silently doing nothing. The migration isnt done until grep comes back empty.

Visual testing catches what compilers cant. The site compiled fine with white text on white backgrounds. Only Playwright screenshots revealed the dark mode propagation failures and missing padding issues.

Was It Worth It?

We went from a site that looked like a themed template to a site that looks like ours. Every color choice is intentional. Every dark mode state is explicit. When we want to change how something looks we change the classes on that element. Not a variable in a theme file that affects 40 other components in ways we cant predict.

The migration took effort.

But the creative freedom we got back? Thats not something a component library can give you.

Built with Elixir, Phoenix LiveView, and plain Tailwind CSS. We use Claude Code for AI-assisted development.

Digi Work