Every two months, a new dashboard. Every two months, the same conversation.
Same hover states. Same font decisions. Same padding debates. Same questions from the same developers who had never seen this component before — because the last developer who built it had moved to a different project, and nothing had been written down, and nothing had been shared, and we were starting from zero. Again.
At some point, I stopped feeling frustrated by this and started feeling something worse: resigned. This was just how it worked. Every product starts from scratch. Every handoff is a tutorial. Every dashboard takes two months to reach a basic structure — with bugs — and another month to stabilise. That's just the cost of building fast.
Except it wasn't the cost of building fast. It was the cost of building without memory.
The Loop Nobody Named
We were building products across agriculture, infrastructure, finance, and climate intelligence. Each product was genuinely different — different clients, different datasets, different problems. But the front-end was doing the same thing every time. Different developers, same components coded from scratch. Same decisions made, unmade, and made again. The same bugs fixed in one product, silently existing in another.
The designers had figured out a workaround: we copied and pasted across Figma files. We'd sync up, show each other what we'd done, keep each other loosely aligned. It wasn't a system — it was individual memory dressed up as process. It worked until someone left, or a new project came in, or I tried to improve an interaction pattern and realised it would only apply to the dashboard currently on my screen. The three older ones, already deployed, would keep the old version forever.
The engineers had it worse. There was no single engineering lead with a horizontal view across all the dashboards. Each product had its own team, its own codebase, its own tribal knowledge. A front-end developer joining a new project wasn't inheriting a foundation. They were starting a new construction from bare earth — and every time we handed them a design, I'd walk them through the same decisions I'd walked through six months ago with someone else.
Two months to basic structure. Then bugs. Then debugging. Then the next project begins, and we do it all again.
"A Design System is for Mature Companies"
When I first proposed building a design system, the engineers actually agreed. They were living in the loop — they felt it most directly. It was the product managers who pushed back.
The feedback was gentle but clear: this wasn't the right time. Design systems were for mature organisations. For companies with super-app experiences and large established teams. For Google and Airbnb. Not for us — a startup moving fast, trying to deliver for demanding clients. We had roadmaps. We had timelines. We couldn't afford to slow down and build infrastructure.
So the design system did what most unscheduled work does: it lived in a Figma file. I kept building it. I kept refining it. The design team got faster — our time to design improved noticeably. But the gap between design and development didn't close, because the system never made it into code. A design system that only lives in Figma is a reference document. It is not a system.
I tried pushing. It didn't stick. The idea couldn't compete with the urgency of whatever was being built that quarter. So I stopped pushing and started showing.
I mapped out every dashboard we'd delivered. Every product in our portfolio. What were the common elements? What decisions had we made twelve times when we only needed to make them once? What was the baseline that every geospatial product needed — regardless of the client, the data type, the use case?
The answer was more obvious than I expected. And it gave me something concrete to bring back to the conversation.
The Moment It Turned
New engineering managers joined. They'd worked in organisations where design systems existed. They walked into our codebase, looked at the duplication, and immediately understood what was happening — not because someone explained it to them, but because they recognised the pattern. They'd seen it before. They knew what it cost.
That was the real unlock. Not a presentation. Not a business case. New people arriving with context that made the problem visible in a way it hadn't been before.
Once engineering was genuinely on board, we aligned with product and started building in earnest — components first, the most repeated elements, then expanding outward. The design team shifted how they worked: instead of designing screens, we designed building blocks. Every new product became an assembly exercise rather than a blank-slate exercise.
The results came in stages. The first dashboard after the system existed: two months, same as before — but cleaner, fewer bugs, faster stabilisation. The second: one month. Then we tested a module reuse on a third delivery. Major components, pre-built. Certain sections of code, already written.
Two days.
A dashboard that would have taken two months now took two days. That's not an incremental improvement. That's a different way of working.
What It Cost
I want to be honest about this part, because most case studies skip it.
Building the system cost time I didn't officially have. It cost stakeholder management that sometimes felt like negotiation and sometimes felt like begging. It cost promises — timelines I said were achievable because I needed to buy space to do the foundational work, knowing full well the foundation would slow us down before it sped us up.
And it cost accuracy. Early versions of the system meant making a trade-off: the components were functional, but not as refined as I would have made them if I'd been designing each one from scratch for a specific product. I chose functionality over finish. Speed of delivery over pixel-perfect UI. That was the right call — but it was still a call, and it made me uncomfortable every time I looked at something I knew could have been better.
Design systems require you to play a long game in an environment optimised for short ones. That tension never fully goes away. You just have to decide which side of it you're on.
What Systems Actually Do
The numbers are real. Forty percent reduction in development effort. Seventy percent faster delivery. I'm not dismissing them.
But the change I felt most wasn't in the metrics. It was in the quality of conversations. Designers stopped debating components and started debating problems. Engineers stopped rebuilding foundations and started building features. Product managers stopped absorbing delays caused by redundant work and started actually planning ahead.
The cognitive load shifted. And when cognitive load shifts, the thinking gets better.
A design system is not a component library. It's a set of decisions that have already been made — so that the people building products can spend their energy on the decisions that haven't been made yet. That's what it actually does. It creates space for harder thinking by eliminating easier thinking.
Systems don't just scale products. They scale decision-making.
If You're Making This Case Right Now
If you're a designer trying to convince your organisation that a design system is worth building — and you're hitting the same wall I hit — here's what I'd tell you:
Stop arguing for the system. Start documenting the cost of not having one. Count the hours. Count the duplicate decisions. Count the bugs that exist in three products because nobody connected the dots. Make the invisible loop visible — because until people can see it, they can't feel how much it's costing them.
And be ready to play the long game. The payoff is real. But it doesn't come in the quarter you build the system. It comes in every quarter after.
Design systems are not about components. They are about creating clarity in environments where complexity is the default. And in data-heavy, fast-moving organisations — that clarity is the rarest and most valuable thing you can build.