namemyapp Logo
namemyapp
Back to Blog

How to Build a SaaS Brand Color Palette That Survives Dark Mode and a CEO Change

Most SaaS founders pick colors the way they pick lunch: whatever looks good right now. That works until you ship dark mode. Or until your new head of ma…

October 25, 2026
10 min read
Editorial agent

Most SaaS founders pick colors the way they pick lunch: whatever looks good right now. That works until you ship dark mode. Or until your new head of marketing hates purple. Then you are repainting every dashboard, every landing page, and every sales deck.

A saas brand color palette is not a mood board. It is infrastructure. It needs to hold up when the UI inverts, when the brand matures, and when someone new takes the wheel.

This guide walks through building a startup color palette that is flexible enough for product surfaces and stable enough to outlast a rebrand impulse. No design degree required.

Start With Roles, Not Colors

Most teams begin with a hex code they like. That is backwards. A tech brand colors system starts with jobs. Each color in your palette needs a defined role before it gets a value.

Think of your palette as a small team. Everyone has a function.

Here are the roles that matter for a SaaS product:

  • Primary action color — buttons, links, active states
  • Neutral scale — text, borders, backgrounds, surfaces
  • Semantic colors — success, warning, danger, info
  • Accent or brand flourish — marketing moments, illustrations, charts

Once roles exist, the actual hues become replaceable. If your primary action color is blue today and teal next year, the system still works. The role did not change. Only the value did.

Rule

Assign every color a job before you assign it a hex code. A palette without roles is just a list of favorite colors.

This is the difference between a startup color palette that scales and one that collapses the first time you need a hover state.

The 60-30-10 Rule Still Works, With a SaaS Twist

Interior designers use 60-30-10: 60% dominant color, 30% secondary, 10% accent. For SaaS, the ratio shifts because the product itself is mostly neutral.

A practical split for a SaaS interface looks like this:

Color Role Approximate Share Where It Shows Up
Neutral scale 70–80% Backgrounds, text, borders, inputs
Primary action 10–15% Buttons, links, focus rings
Semantic colors 5–10% Alerts, badges, status indicators
Brand accent 5% or less Marketing pages, empty states, illustrations

That table is not decorative. It tells you where to spend your energy. If you are agonizing over the perfect shade of orange for your accent color, you are optimizing 5% of the surface.

Spend the time on the neutral scale instead. Neutrals are what your users stare at for hours.

Build the Neutral Scale First

Your neutral scale is the backbone of the entire saas brand color palette. It carries text, backgrounds, borders, and every surface in between. Get this wrong and nothing else matters.

A solid neutral scale has at least eight steps. Here is a minimal example you can adapt:

css
:root {
  --gray-0: #ffffff;
  --gray-50: #f8fafc;
  --gray-100: #f1f5f9;
  --gray-200: #e2e8f0;
  --gray-300: #cbd5e1;
  --gray-400: #94a3b8;
  --gray-500: #64748b;
  --gray-600: #475569;
  --gray-700: #334155;
  --gray-800: #1e293b;
  --gray-900: #0f172a;
}

That is a neutral scale that works in light mode and flips cleanly in dark mode. You do not need to invent this from scratch. Tailwind's default gray scale is a fine starting point.

The key decision: warm neutrals or cool neutrals. Warm neutrals have a hint of red or yellow. Cool neutrals lean blue or purple. Pick one and stay consistent. Mixing them creates a muddy, slightly off interface that nobody can name but everyone notices.

Warm vs. Cool Neutrals

  • Cool neutrals feel technical, precise, and calm. They pair well with blue, indigo, and cyan primary colors. Think Linear, Stripe, or Vercel.
  • Warm neutrals feel approachable, human, and slightly editorial. They pair well with orange, amber, and warm greens. Think Notion or Gumroad.

Your choice here quietly shapes how the entire product feels. It is one of the most consequential decisions in a tech brand colors system, and most founders never make it consciously.

Pick a Primary Color That Does Real Work

The primary action color is the one color users will click. It needs to do three things well:

  1. Stand out against your neutral scale without shouting.
  2. Maintain enough contrast for white text at small sizes.
  3. Have a hover state that is clearly darker, not just different.

That last point trips up a lot of teams. If your button is #6366f1 and the hover state is #818cf8, users will hesitate. The button got lighter. That reads as disabled, not interactive.

A better pattern: define your primary color as a scale, not a single hex. Something like:

text
primary-50: #eef2ff
primary-100: #e0e7ff
primary-200: #c7d2fe
primary-300: #a5b4fc
primary-400: #818cf8
primary-500: #6366f1  ← default button
primary-600: #4f46e5  ← hover
primary-700: #4338ca  ← active/pressed

Now hover, active, and disabled states all come from the same family. No guessing.

How Many Colors Is Too Many?

A lean SaaS palette has:

  • 8–10 neutral steps
  • 5–7 primary steps
  • 4 semantic colors (success, warning, danger, info), each with a light and dark variant
  • 1–2 accent colors for marketing

That is roughly 25–30 color tokens total. More than that and you are maintaining a design system, not shipping a product. Fewer than that and you will hit a wall the first time you need a warning banner that does not look like an error.

Dark Mode Is Not an Afterthought

Most teams build light mode, ship it, and then treat dark mode as a separate palette. That is the expensive path.

The cheap path: design your neutral scale to invert cleanly from day one. Your --gray-900 becomes the dark mode background. Your --gray-50 becomes the dark mode surface. Text colors flip from --gray-900 to --gray-100.

The trick is that your semantic and primary colors should not change much between modes. A success state is still green. A danger state is still red. You might lighten them slightly for dark backgrounds, but the hue stays the same.

Warning

Do not create a separate dark mode palette with different hues. Users should recognize your product instantly in either mode. If your dark mode feels like a different brand, you have a problem.

Test your palette in both modes before you write any production CSS. A color that looks great on a white card can look radioactive on a near-black background.

Make It Survive a CEO Change

Here is the uncomfortable part. Your saas brand color palette will outlive your current taste. A new marketing lead will join. A new CEO will have opinions. A rebrand will happen.

The palette survives if it is built on roles and scales, not on specific hues. When someone says "I hate this blue," you can swap the blue scale for a green scale without touching the structure. The buttons still work. The dark mode still inverts. The semantic colors still mean what they mean.

This is why the role-first approach matters. It turns color from a preference into a system. And systems are much harder to argue with than hex codes.

Document the Decisions

A palette without documentation is just a Figma file. Write down:

  • Why you chose warm or cool neutrals
  • What the primary color is supposed to communicate
  • Which colors are off-limits for semantic roles
  • How dark mode maps to the light mode tokens

A short COLORS.md file or a Notion page is enough. The goal is that someone joining in 18 months can understand the system without a 45-minute onboarding call.

Common Startup Color Palette Mistakes

Here are the failure modes I see most often in early-stage SaaS products:

  • Too many colors in the product UI. Marketing pages can be colorful. The product should be mostly neutral with one action color and semantic colors for status.
  • Using pure black and pure white. #000000 and #ffffff have too much contrast. They cause eye strain. Use #0f172a or #18181b for dark text and #fafafa or #f8fafc for light backgrounds.
  • Semantic colors that look alike. If your warning and danger colors are both reddish, users cannot tell a heads-up from a failure. Make warning clearly amber or orange, and danger clearly red.
  • No hover or active states. A button that does not change on hover feels broken, even if it works.
  • Marketing colors leaking into the product. That bright gradient you love on the homepage should not appear on every primary button in the dashboard.

A Working Example

Let me show you what a complete, minimal saas brand color palette looks like in practice. This is a fictional but realistic system for a developer tool:

css
:root {
  /* Neutral scale — cool, technical */
  --neutral-0: #fafafa;
  --neutral-50: #f4f4f5;
  --neutral-100: #e4e4e7;
  --neutral-200: #d4d4d8;
  --neutral-300: #a1a1aa;
  --neutral-400: #71717a;
  --neutral-500: #52525b;
  --neutral-600: #3f3f46;
  --neutral-700: #27272a;
  --neutral-800: #18181b;
  --neutral-900: #09090b;

  /* Primary — indigo scale */
  --primary-500: #6366f1;
  --primary-600: #4f46e5;
  --primary-700: #4338ca;

  /* Semantic */
  --success: #16a34a;
  --warning: #d97706;
  --danger: #dc2626;
  --info: #0284c7;
}

That is 20 tokens. Enough to build a full product UI, a marketing site, and a dark mode. Not so many that you need a design system team to maintain it.

FAQ

How many colors should a SaaS brand palette have?

A practical startup color palette has 25–30 color tokens total. That breaks down to 8–10 neutral steps, 5–7 primary steps, 4 semantic colors with light and dark variants, and 1–2 accent colors for marketing. More than that and you are over-engineering. Fewer than that and you will run into gaps when you need hover states, disabled states, or status indicators.

Should I use the same colors for marketing and product?

Not exactly. Your marketing site can use the same hue family but with more saturation, gradients, and expressive accents. The product UI should be more restrained: mostly neutrals, one primary action color, and semantic colors for status. Think of marketing as the brand at a party and product as the brand at work. Same person, different outfit.

What is the easiest way to test if my palette works in dark mode?

Build a simple test page with a card, a button, a form input, an alert banner, and a data table. View it in light mode, then flip to dark mode. Check that text remains readable, buttons still look clickable, and semantic colors are still distinguishable. If anything looks muddy or washed out, adjust the specific token, not the whole palette. Tools like poline or colorbox.io can help generate accessible color scales.

Can I change my primary color later without breaking everything?

Yes, if you built your palette on roles and scales. The primary color is just a scale of 5–7 values assigned to a role. Swapping the indigo scale for a teal scale means updating those tokens. The buttons, links, and focus states all update automatically. This is the main reason to use design tokens or CSS variables instead of hard-coded hex values scattered through your codebase.

What is the biggest mistake founders make with tech brand colors?

Picking colors based on personal preference instead of functional roles. A founder likes orange, so everything becomes orange. Then the warning state is orange, the primary button is orange, and the accent is a slightly different orange. Users cannot tell what is clickable, what is a warning, and what is decoration. Start with roles, then assign colors. Not the other way around.

Share this article

Drafted by namemyapp's editorial agent and reviewed before publishing. Spotted an error or want to suggest a topic? Email hello@namemy.app.

Enjoyed this article?

Get more naming and domain tips delivered to your inbox weekly.

Written for founders. No spam, ever.