How to Write a Component That Survives a Rebrand

Every startup rebrands.

It’s as predictable as your first production outage or your marketing team discovering the color purple.
And yet, every rebrand sends developers back into the trenches, rewriting the same components with new tokens, new borders, new “brand vibes.”

But what if your components could survive a rebrand?
Not just once, but twice — without breaking.

Let’s talk about building primitives that don’t panic when the CMO changes fonts.

---

The Art of Layering

The secret is layering. Great components are like onions or ogres: they have layers.

When you design a component, you’re not designing how it looks. You’re designing where its decisions live.

Here’s the survival stack:

Logic → Tokens → Theme → Design System → App

Each layer has a job — and a boundary. Break the boundary, and you’ll be rewriting your entire UI the moment marketing invents “Brand Gradient v2.”

Let’s peel this stack, layer by layer.

---

1. Logic: The Unshakable Core

Logic is the only part of your component that should never change.
It’s the behavior, the state machine, the event wiring — everything the user does, not what they see.

A good Button component, for example, knows how to:

• Handle focus, keyboard, pointer events.
• Manage ARIA roles.
• Respect disabled states and forms.

If your brand redesign breaks this layer, your app has bigger problems than color palettes.
This layer should live in pure, style-free code — something you could render in plain HTML and it would still work.

That’s what headless components are for.
They let you preserve logic while throwing away styles like a snake shedding its skin.

---

2. Tokens: The Atomic Vocabulary

Tokens are the DNA of design.
They’re your app’s definition of what “primary-500” or “space-4” means — abstract, brand-agnostic, reusable.

A rebrand should only rewrite the token file, not the components that use it.

If your button imports a literal hex code like #0070f3, congratulations — you’ve hardcoded sadness into your future.
Use tokens, and your “blue” can become “neon coral” overnight without touching a single component.

In Rad UI, for example, tokens are the lingua franca between Figma and code — the bridge between human taste and machine consistency.

---

3. Theme: The Translator Layer

Themes exist to apply tokens contextually.
They decide which tokens a component should use, depending on mode, variant, or environment.

Dark mode? High contrast mode? Holiday edition?
Themes handle all that — they’re the diplomats negotiating between your components and brand identity.

Think of themes as JSON-shaped agreements between designers and developers:
“Hey, if you call yourself primary, you get this color. Don’t ask where it came from.”

---

4. Design System: The Treaty

A design system isn’t your app.
It’s the ruleset for how your app behaves and feels across surfaces.

It takes the headless logic and the tokens, wraps them in opinionated defaults, and exports taste.
It’s where your team’s visual voice lives — your spacing rhythm, animation timing, and accessibility defaults.

A good design system doesn’t dictate style. It codifies decisions.

When a rebrand happens, you tweak the design system’s mapping layer — not 300 files across your repo.

---

5. App: The Custom Face

Finally, the app layer.
This is where product designers stretch, distort, and remix your system to tell specific stories.

You don’t fight that. You plan for it.

Allow for extension, but not mutation.
Your components should accept composition — like asChild props, slot APIs, and token overrides — so that when the new brand manual drops, your app just adapts.

---

The Two-Rebrand Test

Here’s a fun (and painful) test for your components:

Could your button survive two complete redesigns — a light, minimal one and a maximalist 3D neon one — without rewriting logic?

If yes, you’ve built something future-proof.
If not, you’ve hardcoded someone’s 2023 taste into your product’s DNA.

The web changes faster than any brand guide. Flexibility is not an aesthetic — it’s survival.

---

Closing Thoughts

Every startup rebrands because design is storytelling, and stories evolve.
Your job isn’t to freeze time — it’s to build infrastructure for change.

So next time you write a component, don’t think:

“How do I make this look good?”

Think instead:

“How do I make this survive the next rebrand?”

Because the only thing more expensive than a redesign… is redoing it all again.

---

Rad UI was built with this philosophy in mind — primitives that survive every design era, from skeuomorphic 2009 to glassmorphic 2029.