DEV Community: yang7206

One brand color, three platforms: what actually changes

yang7206 — Sat, 31 Oct 2026 13:48:57 +0000

A while back I inherited a design system that had been ported from web to a mini program. The primary color made it. Almost nothing else did.

The tokens were all there. primaryHover, primaryActive, border, surface, textSub. Someone had copied them into the mini program stylesheet in good faith. Then, one at a time, they became dead weight. border had no consumer, because the mini program draws dividers instead. primaryHover sat there doing nothing, because a finger cannot hover.

The usual explanation is "the port was sloppy." I don't think that's it. The three platforms genuinely have different shapes, and almost nobody writes those shapes down. So I did.

I maintain a palette library with 100 palettes across the three platforms (31 app, 34 web, 35 mini program). Every palette has exactly ten color roles. I compared the role sets, the state transitions and the contrast behavior. All figures below are computed from those 100 palettes, so they describe one particular library and not the industry.

Here's what came out.

Ten roles each, and one shared field name

Put the three lists side by side and the intersection is one field name: bg. That's it. Everything else is named differently, or exists on one platform and not the others.

Purpose	App	Web	Mini program
Primary	`primary`	`primary`	`theme`
Darker / interaction	`primaryDark`	`primaryHover` + `primaryActive`	`btn`
Lighter version	`primaryLight`	none	`tag`
Secondary	`secondary`	none	none
Accent	`accent`	`accent` + `link`	`price`
Text levels	`text` (one)	`textMain` + `textSub`	`textMain` + `textSub`
Divider	none	`border`	`divider`
Container	none	`surface`	`card`
Status	`success` / `warning` / `danger`	none	none
Disabled	none	none	`btnDisabled`

Ten roles on each platform. Same count, different sets. Which explains the dead tokens: the mini program had no place to put success, warning or danger, and no consumer for border. Meanwhile it was missing three roles it actually needed, price, tag and divider, because nobody had added them.

So "one brand color across three platforms" is true of exactly one role. The primary can stay. The other nine have to be rewritten per platform, and someone has to decide what they become.

Web darkens along one line, the app spreads to both sides

Web carries two interaction states. The app carries none, and the reason is the input device rather than the screen. A mouse pointer can hover. A finger has no middle state between pressing and lifting.

Measured across the web palettes here, primaryHover sits 13.9 lightness points below the primary (range 5.3 to 14.2), and primaryActive sits 26.1 points below. The second is about 1.9x the first.

The app does something structurally different. It gives the primary two flanks:

primaryDark: 14.0 points darker than the primary
primaryLight: 32.0 points lighter

The rise on the light side is 2.3x the drop on the dark side. That asymmetry is not arbitrary. The dark variant only ever marks a press. The light variant gets used as a tag background and as the fill of a selected area, which are large surfaces, and a fill that isn't light enough leaves no contrast headroom for dark text sitting on it. The dark side can move a little. The light side cannot.

Working numbers if you're setting these by hand: darken hover by 10 to 14 points, take active to roughly twice that, and push the light variant about twice as far as the dark one in the opposite direction. Narrower than that and the press is invisible. Wider and one tap looks like a different brand.

The mini program hides its accent behind a business word

Web and app both call their accent accent, and it is decorative: badges, highlights, anything that should be noticed without carrying information. The mini program has no accent. It has price.

That rename is the most useful thing in the whole comparison, because it exposes the rule underneath. In a mini program the accent serves a transaction, and price is its only job. Measured here, price sits at a median 4.50:1 against the background, with a low of 3.65:1. Compare that to the decorative accent on the other platforms, which in many palettes sits far below the body text threshold and is fine there.

The generalizable version: whether a color needs to clear a contrast threshold depends on whether it carries information or atmosphere. A decorative accent may sit low. An accent carrying a price, a count or a status may not. Same hue position, two uses, two standards, and the field name is doing the work of telling you which one you're looking at.

Each platform drops what it doesn't need, and the drops are the tell

The omissions are not random. They line up with how each platform organizes a screen.

Web has surface and border, and no status colors. Long pages divide with hairlines and faint fills. A form can run two thousand pixels tall, and a rule tells you something changed.

The mini program has card, divider and tag, and no status colors either. The page is a card stack, one card per unit of information, and the gaps between cards do most of the dividing.

The app has success, warning and danger, and neither surface nor border. Actions on a phone have consequences. A delete or a submit cannot be taken back, so state has to be explicit.

Which settles the first question when porting: don't move colors first. Look at what establishes hierarchy on the target platform. Carrying web colors into a mini program without its spacing gives you cards that collapse into a smear. Carrying app colors to the web leaves three status roles with nowhere to live.

The exception worth knowing about

The primaryLight figure above (32 points lighter) is a median. One palette in the library goes the other way: a primary of #4c8df6 at lightness 63, and a primaryLight of #1e3a63 at lightness 25, darker by 38 points.

That palette is a dark theme. Some dark implementations read primaryLight as "the tinted container for the primary" and return a darkened surface instead of a lightened one. The name didn't change. The value did.

The failure is concrete: if you treat primaryLight as a light fill because of its name, that palette gives you dark navy behind dark text, and the contrast collapses.

So the rule is one line: measure before you trust the name. Compare the lightness of primaryLight against the primary. Lighter, and it's a fill. Darker, and in this palette it's a deep container that wants light text on it. Same check applies to any palette you import and any design system you inherit.

If you only ship one platform, you need four roles

Most projects ship one platform, or ship one and expand later. You do not need thirty roles for that. Each platform has a minimum set, and four roles carry a page:

Platform	Minimum set	What breaks first without it
Web	`primary` + `bg` + `textMain` + `border`	No `border` and tables and forms lose their structure, leaving spacing to do all the work
Mini program	`theme` + `bg` + `textMain` + `card`	No `card` and the card stack flattens into one long column of text
App	`primary` + `bg` + `text` + `primaryDark`	No `primaryDark` and pressing a button produces no feedback at all

Four roles get a usable interface out the door, with three gaps: no secondary text, no accent, and no disabled state. None of that blocks a launch. All of it shows up afterward, one "why does this look off" at a time.

The order to fill the gaps is not a matter of taste. Secondary text first, then disabled states, then accent. The first affects legibility, the last affects looks, and the middle one decides whether people think a button can be pressed.

The short list

If you're doing the port this week:

Leave the primary alone. Recognition depends on it and it has to match across platforms.
Web: add primaryHover (10 to 14 points darker), primaryActive (about double), border, surface, textSub. No status colors.
Mini program: replace the accent with price and hold it to the text standard. Add card, divider, tag, btnDisabled.
App: add primaryDark (14 points darker), primaryLight (32 points lighter, and verify it is actually lighter), secondary, and the three status colors. No surface, no border.
Dark themes: check the direction of every variant. Names lie at the edges.

Where the numbers come from

Every ratio in this post is computed with the WCAG 2.1 relative luminance formula, not estimated by eye, and every figure is regenerated at build time from the palette data rather than typed into the page. The full write-up, the datasets these figures come from, and two more pieces on secondary text contrast and on why card and border colors are nearly invisible, live at paletteget.com/guides. The thresholds and the method are documented at paletteget.com/method.

If you want to check one of your own palettes, the contrast numbers for all three platforms are listed on each palette page, so you don't have to work them out by hand.

One caveat worth stating plainly: this is 100 palettes from one library, curated by one person. It is a decent sample for spotting structural patterns in how the three platforms differ, and it is not a survey of what the industry does. Treat the ratios as evidence that the difference exists, not as targets to hit.

I gave my coding agent a color palette library, and stopped pasting hex codes

yang7206 — Thu, 22 Oct 2026 14:05:41 +0000

I asked Claude for a color palette for a finance app last month. It gave me six hex codes. They looked right in the chat window. In the actual UI, the body text sat on a primary color at about 2.8:1 contrast, which is unreadable for anyone who isn't 20/20, and the "dark mode" surface was a greenish gray that made every card look sick.

The model wasn't being lazy. It has no ruler. It can produce a hex value that "looks like" a dark teal, but it cannot compute that white text on that teal lands at 2.8:1, because nothing in the conversation tells it what the number is. Ask a better question and you get a nicer-looking guess. That's the ceiling.

So I built the ruler.

What PaletteGet is

PaletteGet is a small site with about 90 hand-picked palettes for three surfaces: mobile apps, web, and mini programs (the WeChat-style mini app format). Each palette ships with role colors, measured WCAG contrast for the pairs that matter, and a short editor note about when to use it.

The part that matters here is that it's also an MCP server, so an agent can read it directly:

{
  "mcpServers": {
    "paletteget": { "url": "https://paletteget-mcp.y7206062.workers.dev/mcp" }
  }
}

Drop that into Cursor, Claude Desktop, or any client that speaks Streamable HTTP. No API key, no sign-up, no local process.

Four tools, on purpose

I kept the surface small because tool sprawl makes agents worse, not better:

list_palettes filters by platform and tag
get_palette returns one palette's role colors, contrast, and the editor note
suggest_palette takes a plain-language query ("dark finance app")
get_css_variables returns paste-ready custom properties

That's it. Four tools, read-only.

The conversation that convinced me

Here is the exchange, trimmed:

Me: I need a palette for a dark-mode finance app. Numbers need to be legible.

Agent: (calls suggest_palette with "dark finance app") Ink Blue Night is the closest fit, tagged for finance and analytics apps in dark mode. Background #12161f. Body text #e8ecf4 reads at 15.29:1, AAA. The primary #4c8df6 sits at 5.56:1 against the background: AA for body copy, AAA for large text, so primary-colored links and icons hold up on the page. The amber accent #f2b33d lands at 9.73:1, safe for prices and deltas. One catch: white on the primary measures 3.26:1, enough for large text only, so keep the button fill for big bold labels.

Read that last sentence again. The agent didn't just hand me colors, it told me where each one is allowed. That distinction is what a contrast number buys you: the model stops asserting and starts measuring.

Before, I'd get "here's a nice palette" and find out it was wrong after wiring it up. Now the constraint arrives with the proposal.

Why not just prompt better

Two reasons.

First, arithmetic is not what LLMs are good at, and contrast is arithmetic with a specific formula (relative luminance, then a ratio). A model can approximate it and be wrong exactly often enough to hurt.

Second, the failure is silent. A palette that fails contrast still looks fine to the person choosing it, because contrast failure is a property of use (text on a surface at a size), not of the color swatch. You only discover it when a real paragraph lands on it.

The CSS shortcut

get_css_variables is the tool I use most, because it collapses two steps into one:

/* Ink Blue Night */
:root {
  --color-primary: #4c8df6;
  --color-primary-dark: #2f6bd4;
  --color-primary-light: #1e3a63;
  --color-secondary: #8b7cf6;
  --color-accent: #f2b33d;
  --color-success: #3fbf7f;
  --color-warning: #e8b341;
  --color-danger: #f2685e;
  --color-bg: #12161f;
  --color-text: #e8ecf4;
}

Semantic names, not --blue-500. If I later swap palettes, the components don't change.

What this is not

Not a generator. Roughly 90 palettes, curated, and it grows by one or two a day at most. If you want infinite procedural color, this is the wrong tool.
Not a design system. It gives you color roles and contrast, not spacing, type scales, or components.
Not a hosted service with an SLA. It's a read-only endpoint on a Worker.

Try it

Endpoint: https://paletteget-mcp.y7206062.workers.dev/mcp
Docs: https://paletteget.com/docs/
Source: https://github.com/yang7206/paletteget-mcp
Registry: io.github.yang7206/paletteget

If your agent keeps inventing hex values that fall apart in the browser, give it the ruler and see what changes. Feedback welcome, especially palettes you want that aren't there.