How I Run 4 Distinct Brand Systems Without Losing My Mind (Or Mixing Up the Voice)

The Problem I Created for Myself

I run four products. Each needs its own identity — PromptsRoyale isn't RecruitRocket, and neither should look like they came from the same template. But I'm one person. I can't afford a designer on retainer, and I definitely can't afford to spend an hour finding the right shade of blue every time I need to ship a feature.

The first six months, I winged it. Picked colors in Figma, hardcoded them in components, tried to remember which brand used sentence case in CTAs and which used title case. It worked until it didn't. I shipped a PromptsRoyale button with RecruitRocket's orange. Wrote an email in the wrong voice. Spent twenty minutes hunting down a hex code I'd already defined somewhere else.

GREVEL. Pure gravel.

Design Tokens as a Single Source of Truth

I centralized everything into design token files — one JSON file per brand, stored in a shared /tokens directory at the monorepo root.

// tokens/promptsroyale.json
{
  "brand": "PromptsRoyale",
  "colors": {
    "primary": "#6366F1",
    "primary-dark": "#4F46E5",
    "secondary": "#EC4899",
    "background": "#FAFAFA",
    "text": "#1F2937"
  },
  "typography": {
    "heading-case": "sentence",
    "body-font": "Inter",
    "heading-font": "Cal Sans"
  },
  "voice": {
    "tone": "playful-expert",
    "cta-case": "sentence",
    "avoids": ["workflow", "leverage", "synergy"]
  }
}

Each app imports its own token file at build time. Tailwind reads it, generates the CSS variables, and I never hardcode a color again. Need to tweak the primary blue? One change, one place.

// tailwind.config.js
const tokens = require('./tokens/promptsroyale.json');

module.exports = {
  theme: {
    extend: {
      colors: {
        primary: tokens.colors.primary,
        'primary-dark': tokens.colors['primary-dark'],
        // etc
      }
    }
  }
}

Voice Templates, Not Voice Docs

I don't maintain brand guidelines. I maintain templates.

Each brand gets a Claude Project with a custom prompt that loads its voice tokens. When I need to write email copy, I open the right project. The system prompt already knows:

• PromptsRoyale is playful-expert, uses "you" freely, avoids corporate jargon
• RecruitRocket is authoritative-helpful, leans formal, speaks in benefits
• BuildNotBurn is direct-peer, no fluff, uses BNB vocabulary
• [Product 4] is warm-technical, balances simplicity with depth

I don't remember these rules. I don't need to. The prompt remembers for me.

# PromptsRoyale Voice System Prompt

You are writing for PromptsRoyale, a prompt management tool for developers.

VOICE:
- Playful but expert — you know your stuff, and you're fun about it
- Sentence case for headlines and CTAs
- Uses second person freely ("You're building something cool")
- Never: "workflow", "leverage", "synergy", "unlock"

EXAMPLES:
✅ "Your prompts, organized. Finally."
❌ "Unlock your workflow efficiency"

Every AI interaction starts with context. I'm not keeping four brand voices in my head — I'm keeping four prompts in four Claude Projects.

Component Libraries That Know Their Brand

I don't share components across brands. I share patterns.

Each app has its own /components directory. A Button in PromptsRoyale might look 90% like a Button in RecruitRocket, but they pull different tokens, render different corner radii, use different font weights.

When I need a new component, I copy the pattern from another app, update the import to pull the right tokens, and I'm done. No prop drilling for brand context. No wrapper components. The component knows which brand it belongs to because it lives in that brand's codebase.

// apps/promptsroyale/components/Button.tsx
import tokens from '@/tokens/promptsroyale.json';

export function Button({ children, ...props }) {
  return (
    <button 
      className="bg-primary hover:bg-primary-dark rounded-lg px-6 py-3"
      {...props}
    >
      {children}
    </button>
  )
}

The Build Check

I added a pre-commit hook that validates token usage. If I accidentally reference a color that doesn't exist in the active brand's token file, the build fails. Catches cross-contamination before I even push.

# .husky/pre-commit
node scripts/validate-tokens.js

The script is 30 lines. It checks that every Tailwind class in the diff maps to a defined token. Saved me three times last month.

What Actually Changed

I stopped trying to hold four brands in my head. I built a system that holds them for me. Design tokens for visual identity. Claude Projects for voice. Component patterns instead of shared libraries. Validation that catches mistakes.

Now when I switch contexts — say, from a PromptsRoyale feature to a RecruitRocket bug fix — I'm not rebuilding the brand in my working memory. I'm loading a different token file and opening a different Claude Project. The system handles the rest.

It's not about being a brand genius. It's about not needing to be one.