I am a thief. Not a good one, just a working one. Almost every site I’ve shipped in the last five years has a color system that started its life inside someone else’s product. I open DevTools, I poke around, I copy the hex values into a notes file, I credit the source in a comment, and then I rework the thing until it fits the project. That is the whole job.

If you’re a designer, you already know this. Nobody comes up with a 12-step gray scale on a Tuesday afternoon from first principles. You stand on the shoulders of teams who had a real budget and a real research process, and you rework what they figured out for your own little corner.

So here is the actual list of color systems I keep stealing from, plus the four-step process I use to do the stealing without ending up with something illegible.

Where I steal from

Tailwind’s gray, zinc, and slate scales. This is the one I reach for most. Tailwind ships three near-grays (warm, neutral, cool) with eleven steps each, and the steps are so well tuned that I genuinely cannot do better. I usually pick one (slate for tech-feeling projects, zinc when I want flatter, gray when the brand has any warmth to it) and use the whole 50–950 ramp.

Stripe’s accents. Stripe’s documentation site (the dashboard, too) has a particular blue-purple I keep reaching for. #635BFF as the primary, paired with a denser indigo for headings on light backgrounds. Stripe also gets greens right, which most people don’t. Their success green is muted, almost mossy. Not the screaming Bootstrap-success #28a745 you see everywhere.

Linear’s neutrals. Linear’s whole UI runs on a tight palette of cool dark grays with one or two saturated accents. What I steal from Linear isn’t the hex values, it’s the discipline. Three or four neutrals and one accent, full stop. No twelve shades of brand color. No “secondary CTA” that’s just a slightly different blue.

Apple HIG warning and error. Apple’s system orange (warning) and system red (error) are tuned to feel urgent without being alarming, and they hold up against both light and dark mode. I usually crib those exact values when I’m building any kind of form or destructive-action UI. Whatever Apple’s research budget is on color contrast, mine is smaller.

How to actually steal a color system

The bad version of stealing is opening a screenshot, eyedropping one button, and then trying to reverse-engineer a whole system from one hex code. That ends in tears. Here is what I do instead.

Step 1: pick a base. Find one color in the source system that anchors everything. Usually it’s the brand primary or the densest neutral. For Tailwind slate, that’s slate-900 (#0F172A). For Stripe, it’s their indigo (#635BFF). One number. Write it down.

Step 2: derive the scale. If you’re stealing from a system that publishes a full ramp (Tailwind does, Material does, Radix does), just use theirs. If you’re stealing from a closed system like Stripe’s, you have to build the ramp yourself. I use HSL and walk the lightness up and down in roughly even steps, then fix the ones that look muddy by hand. Tools like uicolors.app or Radix’s color system can short-circuit this.

This is the part where it stops being copying and starts being design work. The base color is the seed. The scale is yours.

Step 3: validate accessibility. Every text-on-background combination you intend to use has to clear WCAG AA. That means 4.5:1 for body text and 3:1 for large text. I run this in the browser with the Stark extension or in Figma’s plugin of the same name. If a combination fails, I either darken the text step or lighten the background step until it passes. No exceptions, no “it looks fine on my monitor.” I have shipped sites that looked fine on my monitor and got an angry email from a reader on a sun-lit train. I am done with that.

Step 4: keep it small. A real color system has maybe 12 to 20 tokens you actually use. --bg, --bg-elevated, --text, --text-muted, --border, --border-strong, --accent, --accent-hover, --success, --warning, --danger, plus dark-mode counterparts. That’s it. If you find yourself adding --accent-secondary-light-2, you have lost the plot.

I write all of this as CSS custom properties at the :root level, which makes the dark-mode story trivial later.

One concrete example

For a small membership site I built last autumn, here is the actual palette I shipped, with sources noted in the stylesheet because I’m not a monster.

• --bg: #FAFAFA – Tailwind’s zinc-50
• --bg-elevated: #FFFFFF – pure white, for cards on the bg
• --text: #18181B – Tailwind’s zinc-900
• --text-muted: #71717A – Tailwind’s zinc-500
• --border: #E4E4E7 – Tailwind’s zinc-200
• --accent: #635BFF – Stripe indigo, lifted from their docs site
• --accent-hover: #4F46E5 – darker step I derived myself
• --success: #16A34A – Tailwind green-600, slightly muted from where I usually go
• --danger: #DC2626 – Tailwind red-600, close cousin of Apple’s system red

Body text on the background hit 16.1:1. Muted text on the background hit 4.7:1, which clears AA but only just. Accent on white hit 4.9:1 for buttons, which is fine for a button label but I would not set body copy in it. The scale lives in a single CSS file, the dark-mode override is another 30 lines, and that has not changed in eight months.

On crediting

I genuinely do put a little comment block at the top of the color section saying where each anchor color came from. Nobody reads it. It is for me, six months later, when I’m wondering why the accent looks vaguely like Stripe’s. Past me already left a note. Past me is a useful colleague.

Anyway, go open DevTools on a site you like and see what they’re using. That’s the assignment.