A pattern shows up almost every time we take over an existing site: buttons that are visually identical but built three different ways in three different files. A blue that's `#0A1F44` in one place and `#0A1E43` in another, close enough that nobody noticed until a designer held two screenshots side by side.
None of this is really about aesthetics — it's about how expensive it becomes to change anything later. Without a shared set of tokens (color, spacing, type scale) and a small library of reusable components, a request as simple as "make our buttons a bit more rounded" turns into a search-and-replace across dozens of files, hoping you didn't miss one.
The fix isn't complicated, and it doesn't require a full design-system team. On every project now, we start with a token file — colors, font sizes, spacing units — defined once and referenced everywhere, plus a handful of base components (buttons, cards, form fields) that every page pulls from. It's maybe a day of extra setup at the start of a project.
That one day pays for itself the first time a client asks for a site-wide change. What used to be a multi-hour hunt-and-fix task becomes a one-line edit to a config file. It also keeps a site visually consistent as more pages get added over time, instead of 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 adding to their site — a blog, new service pages, a redesigned 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.