Multi-brand design systems are a massive waste of time

The premature scaling problem

I was on a Zoom call last Friday with a lead designer. We were building a new component library for a startup that literally launched two months ago. He shared his screen to show me his completely restructured Figma file. He looked incredibly proud.

He had set up four different brand themes using Figma variables. He spent a whole week mapping primitive colors to semantic tokens for brands that do not even exist yet. He created a primary brand, a secondary brand, a dark mode for both, and a high contrast mode for each. The matrix of design tokens was absolutely massive.

I asked him why we needed all of this. He told me that the company might launch a spin-off product next year. He wanted the architecture to be ready for it.

This is a massive trap. Building a multi-brand design system before you actually have multiple brands is an anti-pattern. It slows down development and frustrates everyone involved. You end up maintaining a complex architecture for a future that might never arrive.

The illusion of flexibility

When you build for multiple brands from day one, you complicate every single layer of your tech stack. Let us look at the CSS side of things.

A simple button component suddenly needs a complex theming context in React. Instead of just writing a straightforward CSS file, you end up passing brand props down a massive component tree. Your simple components turn into logic heavy monsters.

Look at this typical multi-brand setup in React:

import { createContext, useContext } from 'react';
import { themeA, themeB } from './tokens';

const ThemeContext = createContext(themeA);

export const ThemeProvider = ({ brand, children }) => {
  const currentTheme = brand === 'brandB' ? themeB : themeA;

  return (
    <ThemeContext.Provider value={currentTheme}>
      <div style={currentTheme.variables}>
        {children}
      </div>
    </ThemeContext.Provider>
  );
};

This looks clean enough here. But imagine scaling this across hundreds of components. Every new developer has to understand the theming context before they can build a simple landing page. They have to know which token to use for a border color because border-subtle changes meaning depending on the active brand.

The cognitive load is completely unnecessary. Most teams just need a solid primary color palette and a working dark mode. That is it.

The maintenance nightmare in Figma

The complexity is not just in the code. It ruins the design workflow too.

Every time a designer wants to introduce a new semantic color, they cannot just add it and move on. They have to define what that color looks like across all hypothetical brands. A simple task like adding a warning background color turns into a data entry job.

I have seen designers spend hours cross checking contrast ratios for a brand theme that nobody actually uses in production. They get bogged down in variable management instead of designing better user experiences. The tool starts dictating the workflow. Figma is brilliant for managing variables but you do not have to use every feature just because it is there.

When you export these tokens using tools like Style Dictionary, the JSON files become absolutely huge. You end up shipping hundreds of CSS variables to the browser that sit there doing nothing. It bloats your stylesheets and makes debugging a nightmare. When a color looks wrong on the staging environment, you have to trace it back through three layers of aliases across four different brand files.

/* This is what over-engineered token output looks like */
:root {
  --core-color-blue-500: #1a56db;
  --core-color-red-500: #ef4444;

  /* Brand A */
  --brand-a-primary: var(--core-color-blue-500);
  --brand-a-danger: var(--core-color-red-500);

  /* Brand B */
  --brand-b-primary: var(--core-color-red-500);
  --brand-b-danger: var(--core-color-blue-500);

  /* Semantic layer */
  --button-primary-bg: var(--brand-a-primary); /* Wait, how do I change this for Brand B dynamically? */
}

This CSS setup usually requires complex build steps to split the themes into separate files. You spend days configuring Webpack or Vite just to swap stylesheets.

But what about future growth?

I know exactly what people say to this. They argue that refactoring a single brand system into a multi-brand system later is incredibly painful. They say it is better to build the foundation right from the start so you are prepared for acquisitions or white label products.

They are not entirely wrong. Refactoring a massive codebase is hard. But building features nobody needs is worse. You should optimise for your current reality. If you only have one brand, build a fast and reliable system for that single brand. You can cross the multi-brand bridge when a client actually pays you to do it.

Keep it simple and automate the rest

Honestly, the best approach is to start with a flat token structure. Use semantic names that make sense for your current product. Build a solid dark mode and stop there.

If you absolutely must support multiple brands because you already have them, you need to remove the human error from the equation. You cannot manage that much complexity manually. I actually built a tool to solve this specific pain point when I was drowning in token updates.

I created a plugin called Design System Sync. It exports Figma design tokens directly to GitHub or Bitbucket via automatic pull requests. If you are managing multiple modes or brands, it handles the visual diffs and generates the CSS variables for you. You can grab it from the Figma Community if you want to stop copying and pasting JSON files all day.

Stop future proofing your design tokens for brands that do not exist. Build what you need today.

Are you currently maintaining a multi-brand system that only has one real brand?