The hover state that started it all
A design review last Monday morning really got under my skin. Our lead designer noticed a subtle mismatch in a button hover state. I opened the component file to check the code. Right there in the styled component was a hardcoded #3B82F6.
The problem is our primary brand blue changed to #2563EB three months ago.
This developer had just copied the hex code straight from the Figma inspector. They pasted it into the CSS and moved on to the next ticket. It worked perfectly on their machine. It passed the visual review for that specific PR. But it created a tiny bit of technical debt that eventually broke our visual consistency.
This happens everywhere. I see it in almost every codebase I audit. We spend weeks arguing about component architecture and state management. Then we just throw raw hex codes into our styles like it is 2010.
It needs to stop.
The find and replace nightmare
Let us look at a really common scenario. You are building a new dashboard. You need a subtle grey border. You grab #E5E7EB and drop it in.
.card {
background-color: #FFFFFF;
border: 1px solid #E5E7EB;
color: #111827;
}
Enter fullscreen mode Exit fullscreen mode
A month later the design team decides all borders need to be slightly darker for accessibility. They want #D1D5DB. You open your code editor and do a global search for #E5E7EB.
You find 47 results. But wait. Are all of these borders? Some of them are background colours for disabled buttons. Some are divider lines. You cannot just do a blind find and replace. You have to manually check every single instance. A five minute design tweak just became an hour of tedious code archaeology.
This is a massive waste of developer time. It also introduces a huge risk of human error. You will inevitably miss one instance or accidentally change a background colour that happened to share the same hex value.
The dark mode scaling problem
The pain gets much worse when you introduce dark mode. If you use raw hex codes you have to write completely separate style blocks for your dark theme.
.button-primary {
background-color: #2563EB;
color: #FFFFFF;
}
@media (prefers-color-scheme: dark) {
.button-primary {
background-color: #3B82F6;
color: #1F2937;
}
}
Enter fullscreen mode Exit fullscreen mode
Now imagine doing this for fifty different components. Your CSS file sizes explode. Your maintenance burden doubles. Every time a colour changes you have to update it in two places. If you forget one the whole UI looks broken for half your users.
It makes your components incredibly rigid. A simple button suddenly needs to know entirely too much about your global theme configuration.
The multi-brand chaos
This scales terribly if you build white label products. I worked on a SaaS platform last year that had to support five different client brands.
The previous team had tried to solve this with massive Sass maps full of hex codes. Every time they onboarded a new client they had to duplicate hundreds of lines of colour definitions. The compilation times were awful. The developer experience was miserable.
Every new feature required testing across five hardcoded themes. It was a complete disaster for productivity.
The counter argument
I know what you might be thinking right now. Setting up a full token system feels like overkill for small projects. Sometimes you just need to ship a quick landing page by Friday. You do not want to spend two hours configuring CSS variables before you even write a line of markup.
I get that completely. Speed matters. But the reality is that copying and pasting hex codes is a false economy. You save five minutes today to lose five hours next month.
Semantic variables are the only way
The solution is actually very simple. You just need to stop thinking about colours and start thinking about intent.
We should never write #2563EB. We should write var(--color-primary-base). We should never write #E5E7EB. We should write var(--border-subtle).
:root {
--color-primary-base: #2563EB;
--border-subtle: #E5E7EB;
--text-main: #111827;
}
.card {
border: 1px solid var(--border-subtle);
color: var(--text-main);
}
Enter fullscreen mode Exit fullscreen mode
When the design team updates the brand you change one line of code. When you need dark mode you just redefine those variables in a media query or a data attribute. The component CSS never changes. It just works.
Connecting the source of truth
The real challenge is keeping those variables in sync with the design team. Designers work in Figma. Developers work in code editors.
This exact friction is why I built Design System Sync. It is a tool that bridges this gap completely. You define your colours and variables in Figma. The plugin exports those exact design tokens directly to GitHub or Bitbucket via automatic pull requests.
It supports standard W3C Design Tokens and raw CSS variables. It handles all the formatting for you. It even does visual diffs so you can see exactly what changed before you merge. You can check out the website to see how it works. You can also grab it directly from the Figma Community.
When you automate the handover you completely remove the temptation to hardcode things. The variables are just there waiting for you in your codebase.
So look at your main stylesheet today. How many raw hex codes are sitting there waiting to break your next redesign? Are you really saving time by skipping variables?