It always arrives the same way. A friendly message, late in the afternoon, two days before launch:

"Love it! Just one small thing. Can we make the buttons a bit rounder and the blue slightly warmer? Should only take five minutes."

Reader, it did not take five minutes.

To be fair, the person asking isn't wrong. From the outside, it looks small. It's a colour and a curve. The trouble is that what's small to see and what's small to change are two completely different measurements, and only one of them is visible from the outside.

A short play in four acts

Most developers have starred in this one at least once. I certainly have.

Act one, 4:47 pm. Me: "Sure, no problem." I find the button style. I change the radius and the colour. Five minutes. I am a genius.

Act two, 4:58 pm. The buttons on the checkout page didn't change. Those are different buttons. Someone (probably past me) copied the styles "just for this one page".

Act three, 5:30 pm. There are now four blues. The original blue, the new warmer blue, a blue that was in the old modal, and a blue that turns out to be the original blue with 2% opacity on top of a grey background. Nobody can tell them apart except the client, who can.

Act four, the next morning. The mobile app still has the old buttons, because the app has its own styles. The PDF invoices use the old blue. The email templates are tables from a simpler time and haven't changed since. "Small thing" is now a ticket with sub-tasks.

What "small" actually touches

❌ The same button copy-pasted into more templates than anyone wants to admit, each with a slightly different class name.

❌ Colours written as raw hex codes in dozens of places, plus a few rgba() versions someone calculated by hand.

❌ A web portal, a mobile app and an email template that all "match" by coincidence, not by design.

❌ Rounder buttons that suddenly don't fit in a table row, so now the table needs adjusting.

❌ The new warmer blue failing contrast on white text, which you only notice when you actually check.

❌ Screenshots in the help guide that are now all slightly wrong.

❌ And my favourite: "Actually, can we see it next to the old one?" Which means both versions need to exist at the same time.

The real lesson: the change was never the problem

Design changes are normal. Clients see the product properly for the first time when it's nearly finished, and of course they have opinions then. Brands evolve. That's not a failure, it's how products get better.

What turns a five-minute change into a two-day change is how the code was built. And that part is completely on us.

What actually makes small changes small

✅ Components, not copies. One Button component (in Blade, React, React Native, whatever you use) with variants like primary, secondary and danger. When the radius changes, it changes in one file. If you find yourself copying a button's classes to "just tweak one thing", add a variant instead.

✅ Design tokens. Name your decisions instead of repeating raw values. Colours, spacing, radii and font sizes live in one place:

:root {
  --color-primary: #2563eb;
  --color-primary-hover: #1d4ed8;
  --radius-control: 8px;
  --space-3: 0.75rem;
}

.btn {
  background: var(--color-primary);
  border-radius: var(--radius-control);
  padding: var(--space-3) calc(var(--space-3) * 2);
}

Tailwind users get the same idea through the theme configuration; in Tailwind 4 that's the @theme block in your CSS. For a mobile app, export the same token values to a shared file so web and app genuinely match instead of approximately matching. Now "warmer blue" is one line, and the four mystery blues can't exist.

✅ Estimate the ripple, not the change. When someone asks "how long?", don't answer for the visible part. Ask yourself: where else does this appear? Web, app, emails, PDFs, docs? Then give a range: "If it's only the web buttons, an hour. If it should match everywhere, including the app and emails, a day or two." That isn't being difficult. It's giving them a real choice.

✅ Show it before you build it all. Change one page, send a screenshot, get a yes. Then roll it out. It saves you from building "warmer blue" three times while the right warmth is negotiated.

✅ Write it down. A change made two days before launch should be a ticket, even a tiny one. Future you will want to know why the blue changed.

Epilogue

The way this story usually ends: the buttons get rounder, the blue gets warmer, and honestly, it often does look better. And somewhere in the codebase there is now exactly one variable called --color-primary, born from pain, protecting all future versions of me.

What's the "small change" that taught you the most? Bonus points if it involved the word "just".