There's a pattern we see almost every time we inherit an existing site: three buttons that look identical but are each coded differently, in three different files. A blue that's `#0A1F44` in one spot and `#0A1E43` in another — close enough that nobody caught it until a designer put two screenshots side by side and asked why they didn't match.
It was never really about how it looks
This isn't an aesthetics problem, even though it looks like one. It's about how expensive it gets to change anything later. Without a shared set of tokens — colour, spacing, type scale — and a handful of reusable components, a request as simple as "make the buttons a bit more rounded" turns into a search-and-replace across dozens of files, hoping nothing got missed.
The fix genuinely isn't complicated, and you don't need a dedicated design-system team to do it. On every project now, we start with a token file — colours, font sizes, spacing units, defined once and pulled in everywhere — plus a small set of base components (buttons, cards, form fields) that every page builds from. It costs maybe a day of extra setup at the start.
Where that one day actually pays off
That day pays for itself the first time a client asks for a site-wide tweak. What used to be a multi-hour hunt-and-fix job becomes a one-line edit to a config file. It also keeps the site visually consistent as pages get added over time, rather than slowly drifting as different people — or different deadlines — touch different corners of the codebase.
The clients who feel this most are the ones planning to keep building on the site — a blog, new service pages, a refreshed section every year or two. A design system isn't overhead on a small project. It's what keeps a small project small as it grows.