Most of the writing about design systems is written by people who built them for large teams, at well-resourced companies, with dedicated time and tooling budgets. It is useful writing. It is also written for a situation that most designers and developers building real products will never be in.
The reality for a solo practitioner is different. You are not staffing a design systems team. You are not writing contribution guidelines for thirty engineers. You are one person trying to build something consistent enough that it does not become a liability as the product grows, without that effort becoming a second job that competes with the actual product.
I built a design system alone, in Figma, for a product I was designing and developing simultaneously. This post is about what that experience taught me: what was worth the investment, what I would approach differently, and what I wasted time on because I was solving for the wrong goal.
The wrong goal, it turned out, was building a system that scales. What I actually needed was a system that is consistent today and flexible enough to grow without being rebuilt. Those sound similar. They produce very different systems.
The wrong goal is building a system that scales. The right goal is building a system that is consistent today and flexible enough to grow without being rebuilt.
WHY THE WRONG GOAL IS SO EASY TO ADOPT
Design system content is aspirational by nature. The examples are polished. The documentation is thorough. The component libraries are comprehensive. Reading enough of it creates a mental model of what a design system is supposed to look like, and that model is almost always bigger and more elaborate than what a solo practitioner actually needs.
So you start building toward that model. You create a full token structure before you have designed enough screens to know which decisions are actually recurring. You document components before the components themselves are stable. You invest in a level of abstraction that makes sense when ten engineers are consuming the system and makes no sense when the only consumer is you.
The overhead accumulates quietly. Maintaining the system starts to feel like work that competes with using it. And at some point you realise that the system you built is designed for a team that does not exist yet, at a scale you have not reached, for a product whose requirements are still changing.
The discipline that actually serves a solo practitioner is narrower and more honest: build the minimum system that eliminates the decisions you would otherwise make repeatedly, and no more.
WHAT I BUILT IN FIGMA AND WHY
Everything lived in Figma. No Storybook, no design tokens exported to code, no separate documentation site. Just a well-organised Figma file that served as the single source of truth for every visual decision in the product.
The structure was straightforward.
A foundations page
One page for the decisions that everything else inherits from. Colour styles, text styles, spacing values, border radius, and shadow definitions. These were defined once and applied as Figma styles throughout every component and every screen.
The discipline here was restraint. Not every colour the product uses needs a named style. The ones that carry meaning, primary, secondary, surface, border, error, success, need names. The rest can be one-off values. Naming everything creates maintenance overhead without adding clarity.
A components page
One page for reusable UI elements. Buttons, inputs, cards, badges, navigation elements, modals. Each component built as a Figma component with variants for the states that actually exist in the product: default, hover, active, disabled, error.
The principle I applied consistently was to only build variants I had already designed in context. Not variants I might need. Variants that existed somewhere in the product already. This kept the component library grounded in real decisions rather than speculative ones, and it meant every component had a concrete use case rather than an abstract one.
A patterns page
One page for recurring compositions: form layouts, empty states, loading states, error states, page headers. These are not components in the atomic sense but they are decisions that recur and benefit from being made once rather than remade on every screen.
This page turned out to be more valuable than the components page in day to day practice, because the decisions it captured were higher level and more consequential. Getting the empty state pattern right once meant every empty state in the product communicated consistently, without revisiting the decision each time.
A patterns page turned out to be more valuable than the components page. Higher level decisions, made once, applied everywhere.
WHAT I WOULD APPROACH DIFFERENTLY
The honest answer is not that I made one big mistake I would undo. It is that I consistently solved for the wrong level of abstraction in the early stages, building infrastructure for decisions that had not stabilised yet.
I defined tokens before I had enough screens
Token structures make sense when you have enough design decisions to know which values are truly recurring and which are one-offs. In the early stages of a product, you do not have that information. You have guesses.
I built a colour token structure early, based on what I thought the product would need, and revised it three times as the product evolved. Each revision required updating every component that referenced the old tokens. The overhead was not catastrophic but it was real, and it was entirely self-inflicted.
The better approach is to use direct Figma colour styles in the early stages and only introduce a token layer once the colour decisions have stabilised enough that you are confident they will not change shape again. Tokens are a tool for managing scale. They are overhead before you need that scale.
I documented components before they were stable
There is a version of design system discipline that says: document as you build. Write the usage guidelines for each component as you create it. That advice is right for a team where multiple people need to understand the decisions you made.
For a solo practitioner, it is premature. The components I documented earliest were the ones I revised most, which meant the documentation was wrong almost as soon as it was written. Keeping it accurate added work without adding value, because the only person reading it was me and I already knew what had changed.
I would now document only when a component is genuinely stable, meaning it has been used in multiple contexts and survived those uses without significant revision. Before that point, a brief annotation in the Figma file is enough.
I built components I was not ready to use
Early enthusiasm for the system led me to build components speculatively, for screens I had not designed yet, for interactions I had not fully thought through. Several of those components were never used. Others were used once and then revised so substantially that the original component bore no resemblance to what ended up in the product.
The constraint I now apply is simple: a component does not get built until it is needed by a screen I am actively designing. Not soon. Now. This keeps the library lean and ensures every component has a real use case driving its design rather than a hypothetical one.
WHAT WAS GENUINELY WORTH THE INVESTMENT
For all the caveats above, building a design system alone was worth doing. The discipline it imposed on the product was real and the compounding returns were visible over time.
Consistency became automatic rather than effortful. Once the foundations were defined, decisions that used to require deliberation became non-decisions.
Iteration got faster. Changing a primary colour across the entire product took thirty seconds because it was defined in one place. Without the system it would have taken hours and still missed something.
Handoff became possible. When the product reached a point where other people needed to build on it, the system gave them a foundation to work from rather than requiring them to reverse-engineer decisions from the existing screens.
The product felt more considered. Consistency at the component level produces a quality of finish that is difficult to achieve any other way, and it is immediately visible to anyone who interacts with the product professionally.
THE PRINCIPLE THAT WOULD HAVE SAVED ME TIME
If I could go back to the beginning with one piece of advice, it would be this: build the system in response to the product, not in anticipation of it.
Every component, every token, every pattern should exist because the product already needed it, not because a comprehensive design system would include it. The system grows as the product grows, and the decisions it captures are real ones rather than speculative ones.
This produces a smaller system than most design system content would have you build. It also produces a system you will actually maintain, because the overhead is proportional to the value it delivers, and because every part of it is grounded in a real decision that the product required you to make.
CLOSING THOUGHT
A design system built alone is not a smaller version of an enterprise design system. It is a different thing entirely: a personal discipline for making recurring decisions once and applying them consistently. The goal is not comprehensiveness. It is clarity, maintained over time, by one person, without it becoming the product instead of serving it.