A design system will pay for itself within a year. I know that sounds like the kind of thing someone says right before trying to sell you one, but stick with me - because the maths is surprisingly hard to argue with, and it's not really about design at all.
Last year, we were about eight weeks into a website rebuild for a mid-sized professional services firm - around 200 people, four offices, the usual shape. The development team flagged that they were spending roughly 30% of their sprint time building variations of components that already existed. Not because anyone had asked for variations. Because the design files had drifted. A button with rounded corners here, a slightly different one with square corners there. A card component with 16px padding on one page and 24px on another. Nobody had noticed during the design phase because each page looked fine in isolation. But when you're building it, every inconsistency is a new conversation, a new decision, and new code.
That's a cost problem. The kind that doesn't show up in your project budget as a line item - it just quietly makes everything take longer.
I should probably define this before we go further, because the term gets thrown around in a way that makes it sound more complicated than it needs to be.
A design system is a shared library of reusable components - buttons, forms, cards, navigation patterns, typography rules, colour definitions - that both designers and developers work from. Think of it like a box of Lego bricks that everyone agrees to use. The designer picks from the box. The developer builds with the same box. When someone wants to change the colour of every primary button across the entire site, you change it once in the system and it updates everywhere.
That's the core idea.
The reason it matters commercially - and this is the bit to focus on if you're the one signing off the project budget - is that without a design system, your designers and developers are essentially speaking different languages. The designer creates a page layout in Figma. The developer interprets it. Somewhere in that interpretation, things drift. Spacing changes. Fonts get approximated. Interactive states get missed. Every one of those micro-misalignments costs time to identify, discuss, and resolve.
With a design system, there's a shared vocabulary. The designer says "use the primary card component with the large heading variant." The developer knows exactly what that means because they're looking at the same documented, coded component. No interpretation required.
Most articles about design systems lose their audience around here. They start talking about atomic design principles and token-based theming and - honestly, I can feel you glazing over already. Fair enough.
Let's talk money instead.
Faster development cycles first. When components are predefined and documented, developers don't rebuild things from scratch for every page. We've seen this reduce front-end development time by 25-40% on builds where a design system was established early. On a project with, say, £150k of development cost, that's £37k-£60k of efficiency. Not theoretical efficiency - actual hours not spent rebuilding things that already exist.
QA cycles are shorter too, because there are fewer "is this right or is this a bug?" conversations. I remember one project - before we were as disciplined about this as we are now - where we logged over 80 QA tickets that turned out to be design inconsistencies, not development bugs. Each one required a designer to check the intent, a developer to adjust the code, and a QA person to verify the fix. At a blended rate, that's probably £8k-£12k of time spent on problems that shouldn't have existed.
Then there's handover. When a project moves from your external partner to your internal team - or when a new developer joins - a design system acts as the manual for how your site is built. Without it, every new person has to reverse-engineer the decisions made during the build. I've seen handovers that should take a week stretch to six weeks because nobody documented the component logic.
And this is the big one: the build phase is maybe 20% of the total cost of ownership of a website. The other 80% is what happens after launch - updates, new pages, new features, content changes, design refreshes. Every single one of those tasks is cheaper when there's a design system in place. Every. Single. One.
The payback period we typically see is 6-12 months. After that, the design system is saving you money every quarter.
Here's something that might resonate if you've been through a website build before. The project finishes. It looks great. Everyone's happy. Three months later, your marketing team wants to add a new landing page for a campaign. Simple enough, you'd think.
Except nobody on your team knows how to build a new page that looks consistent with the rest of the site. The spacing feels off. The fonts don't quite match. The buttons look slightly different. So you call the agency. The agency charges you for a developer to build what should have been a straightforward page. Maybe half a day's work, maybe a full day. £500-£1,000, let's say.
Now multiply that by every time your team wants to make a change over the next three years.
We'll sort out a design system after the build. Right now we need to focus on delivery.
I hear this a lot, and I get it. When you're in the thick of a build, adding anything to the scope feels like a risk. You've got a deadline, a budget, and a list of features that's already longer than anyone's comfortable with. Spending time and money on something that feels like documentation rather than delivery is a hard sell internally.
But building a design system during the build isn't additional work. Most of the work is already happening. Your designers are already making component decisions. Your developers are already writing component code. A design system just means those decisions are captured, documented, and made reusable - rather than thrown away after each page is built.
The cost of establishing a design system during a build is maybe 5-10% of the overall project budget. Retrofitting one after the build? Easily 3-4x that, because you're auditing everything that exists, reconciling inconsistencies, and rebuilding components to a standard they should have been built to in the first place.
It's like insulation, honestly. You can install it while the walls are open during a renovation, or you can rip them open again later. Same outcome, wildly different cost.
I want to head off something I see happen quite often. A firm hears about design systems, gets excited, and then someone Googles what a "mature" design system looks like - maybe they find IBM's Carbon or Google's Material Design - and suddenly the whole thing feels impossibly ambitious. Those are design systems built by hundreds of people over many years. That is not what you need.
What you need is a foundation. A consistent set of components that cover 80-90% of what your site does, documented well enough that someone who wasn't in the room during the build can understand and use them. Buttons that behave the same way everywhere. A typography scale defined once, not reinvented on every page. Spacing that follows a predictable pattern.
That's achievable in any well-run build. It doesn't require a separate workstream or a dedicated design systems team. It requires your delivery partner to be disciplined about how they work - to build components once, document them, and reuse them rather than taking shortcuts.
And actually, this is a pretty good litmus test for the quality of your delivery partner. If they're not talking about component reuse, documentation, and design-development handoff, they're probably building your site the expensive way.
Which raises a question worth sitting with: why don't more agencies recommend this by default? Some genuinely don't work this way - it requires discipline and upfront investment in process that not everyone has. But there's also a less flattering explanation. Agencies that build without a design system tend to get more ad-hoc work after launch. Every "can you just add a page that looks like the homepage" request is billable. The incentives aren't always pointing in your direction.
Let me give you a concrete example. We rebuilt a site for a consulting firm last year - about 40 pages, headless CMS, nothing wildly complex. During the design phase, Nichola and the design team identified around 35 distinct components that would cover the entire site: cards, heroes, text blocks, CTAs, testimonial modules, team grids, the usual suspects.
Each component was designed with defined variants - a card with an image and one without, a CTA in dark mode and light mode. Each variant was documented in Figma with clear specifications: spacing, typography tokens, responsive behaviour, interactive states. The developers built each component once, with the variants baked in.
When the client wanted a new page type six weeks after launch - a campaign landing page they hadn't originally briefed - the marketing team built it themselves using existing components. No design time. No development time. They dragged components into the CMS, populated them with content, and published. About 90 minutes. Total cost to the firm: zero, beyond the person's time.
Without the system, that same page would have meant a brief to the agency, a designer creating a bespoke layout, a developer building it, QA checking it. Maybe two weeks and £3,000-£5,000, depending on complexity. For a single page.
If you're about to commission a website build, or you're in the middle of one, these are worth putting to your delivery partner. Not to catch them out, but to understand what you're actually getting for your money.
"What design system are you building, and when do we get it?" The answer should be specific. You should hear about a component library in Figma, with a corresponding coded component library. You should hear about documentation - not a 200-page manual, but clear notes on how each component works, what variants exist, and how to use them. If the answer is vague - "we'll make sure everything is consistent" - push harder. Consistency without documentation is just good intentions that evaporate when the project team moves on.
"How will our internal team use the design system after you're gone?" This is the question that separates partners who are building for the long term from those who are building for the invoice. A good answer involves a handover session, written documentation your team can actually reference, and components built in a way that your CMS supports - so your content editors can assemble pages from predefined blocks without needing to call anyone. A bad answer is silence, or something about "ongoing support packages."
"How will the design system be maintained as we evolve the site?" Things change. You'll add new page types, new features, maybe a new service line. A good design system has a clear process for how new components get added: who designs them, who builds them, how they get documented, and how you ensure they don't break what already exists. This doesn't need to be complicated, but it does need to exist. No plan for maintenance means the design system is out of date within six months of launch, and you're back to the expensive, inconsistent approach you were trying to avoid.
I'll be blunt. If your delivery partner builds your site without a design system, you're going to pay more. Not during the build - during the build it might actually look slightly cheaper because they're moving fast and not "wasting time" on documentation. Over the next three to five years, though, every change will cost more, take longer, and introduce more inconsistency.
I was talking to the marketing director at a law firm a few months ago - not a client, just a conversation at an event - and she told me they'd spent more on ad-hoc development requests in the two years since their site launched than they'd spent on the original build. Most of those requests were things like "make this page match the other pages" or "add a new section that looks like the one on the homepage." Work that would have been trivial - or unnecessary - with a design system in place.
That's not unusual. We hear versions of that story regularly. The original build comes in on budget, everyone celebrates, and then the slow bleed starts. A few thousand here, a few thousand there, and within 18 months you've spent more on patches and tweaks than a design system would have cost ten times over.
Design systems don't have the glamour of AI strategy or the urgency of a security breach. Nobody's going to bring this up in a board meeting as a strategic priority. But the things that quietly cost you money are rarely the things that make headlines - they're the accumulated friction of systems that weren't built to be maintained, decisions that weren't documented, and shortcuts that felt sensible at the time.
If you're about to invest £100k, £200k, or more in a website rebuild, spending 5-10% of that on a design system isn't a luxury. It's arguably the highest-ROI decision in the entire project. And if your agency isn't recommending it, I'd want to understand why - because the answer will tell you quite a lot about whose interests they're working in.
If you want to benchmark how well your current digital foundations are set up for long-term efficiency - including how maintainable and well-documented your platform actually is - our Fragility of Digital Foundations scorecard takes about ten minutes and has a habit of surfacing things people weren't expecting.