> Blog post by Lokesh Saini
> Canonical (HTML): https://www.lokeshsaini.com/blog/stopped-building-the-design-system-first

The conventional advice is to build the design system first. Nail down your tokens, your spacing scale, your component library. Then draw screens on top of a solid foundation.

It sounds disciplined. In practice, it is one of the slowest ways to start a project.

I changed how I think about this during a six-week engagement redesigning billing workflows for a healthcare clinic. There was no time to build a foundation and then build a product on top of it. So I tried something different: I built both at the same time.

## The Problem With the Foundation-First Approach

When you build a design system before you have real screens, you are making decisions without evidence.

What components do you need? You do not know yet. What spacing values make sense for this specific product? No idea. What states does a form field need? Probably more than you think, once you start designing actual flows.

The result is a design system shaped by intuition rather than by the product it is supposed to serve. You end up with a library of components that look plausible in isolation but do not quite fit the screens you actually need to build. Then you spend a week refactoring the system you just spent two weeks building.

## The Parallel Approach

On the healthcare billing project, I started with wireframes. No components, no tokens, no system at all. The wireframes were there to think: what looks like six screens on paper turns out to be closer to forty states once you include branching logic, error handling, and role-based views. That complexity was not visible until I was actually drawing it.

Once the wireframes revealed the real shape of the product, I moved into high-fidelity screens and built the design system alongside them. Not before. Not after. In parallel.

The first few screens were slow. Every element I placed had to be decided from scratch. Color, spacing, typography, shadow treatment.

No shortcuts. I was paying a tax on every screen.

## The Compound Returns

Around the midpoint of the project, something shifted. I had enough components that each new screen was not starting from zero. A form field pattern I built for the patient intake flow transferred directly to the claim submission workflow. A status badge I designed for billing states worked across half a dozen other places with a single token change.

The system started paying me back. Each new screen contributed components back into the library, and each addition made the next screen cheaper to build. The early tax on individual screens turned into a dividend on every screen that came after.

By the final weeks, screens that should have taken half a day were taking an hour. Not because the work was simpler. Because the work had already been done once, in a slightly different context, and the system captured it.

## What Shipped at the End

The engagement finished in six weeks with a production-ready package: research, wireframes, high-fidelity prototypes, a design system, and developer documentation. The client later described the handoff as clean. The developer picked up the system and built consistently without needing to reverse-engineer design decisions from individual screens.

That outcome was a direct result of building the system alongside the work. If I had spent the first week building a design system, I would have been building the wrong system. The right system could only emerge from the actual design problems the project contained.

## The Rule That Changed

I now resist building the foundation before I know what it needs to hold.

That sounds obvious in retrospect. Of course the system should fit the product. But there is a strong pull toward the opposite: toward investing in infrastructure early because it feels responsible. It feels like you are doing the right thing.

The problem is that "responsible" infrastructure built before you have evidence is just technical debt with better posture. You are still guessing. You just have more committed to the guess.

The better approach is to let the screens generate the system. Stay in wireframes long enough to understand the real complexity of the product. Then draw screens and extract components as they appear, rather than predicting what components you will need. By the time you are done, you have a design system that fits because it was built from the inside out.

The foundation is real when it has something to hold.