You Don’t Need a Design System. You Need Design Discipline.

At some point in every early-stage startup, someone says it. “We should build a design system.”

And everyone nods. It sounds mature. It sounds like something real companies do. It goes on the roadmap. A designer spends three weeks building a component library in Figma. A developer starts setting up tokens. There are meetings about naming conventions.

Meanwhile, the actual product is still broken.

What a design system is actually for

A design system exists to solve a coordination problem at scale. When you have multiple product teams, multiple designers, multiple codebases, things drift. Components get rebuilt from scratch. Buttons look different across pages. Typography is inconsistent between products. A design system is the infrastructure that keeps everything coherent when the humans maintaining it can no longer keep it coherent in their heads.

That is a real problem. It is not your problem right now.

If you have one designer, or two, or none, you do not have a coordination problem. You have an execution problem. And a design system will not fix it. It will make it worse by adding a layer of abstraction between your team and the work that actually needs to get done.

The design system trap

Here is what actually happens when an early-stage startup builds a design system too soon.

The system becomes the product. Instead of designing for users, the team starts designing for the system. Decisions get made based on what fits the component library, not what solves the problem. Adding something new requires updating the system first. Changing something requires a conversation about whether it belongs in the system or not.

The system is meant to serve the product. But now the product is serving the system.

And underneath all of it, the real issues are still there. Inconsistent spacing. No clear visual hierarchy. Onboarding that confuses people. An empty state nobody designed. But at least the button component is documented.

What discipline actually looks like

Design discipline is not a Figma library. It is a set of decisions, made once, that everyone on the team respects.

One typeface. Picked and stuck to. Not revisited every sprint.

A spacing scale. Four values. You use those four values and nothing else. Not because a system enforces it, but because everyone agreed and everyone holds it.

A colour palette small enough to memorise. A primary, a neutral, a destructive. Done.

A shared understanding of what the product voice sounds like. So when someone writes a button label or an error message, it sounds like it came from the same place as everything else.

None of this lives in a tool. It lives in the heads of the people building the product. It gets maintained through taste, through consistency, through someone caring enough to push back when something feels off.

That is design discipline. And it is available to you right now, today, with whatever team you have.

The question worth asking

Before you start building a design system, ask yourself what problem you are actually trying to solve.

If the answer is “our product looks inconsistent,” a design system is not the answer. The answer is making fewer decisions more consistently.

If the answer is “onboarding is unclear,” a design system is not the answer. The answer is fixing onboarding.

If the answer is “we are scaling to five product teams and things are starting to drift,” now you are talking about a real design system problem. Now it makes sense.

A design system built before you have that problem is not an investment. It is a distraction dressed up as professionalism.

When you actually need one

You will know when you need a design system because you will feel the pain of not having one. Designers will be rebuilding the same components independently. Developers will be writing the same CSS in three different files. A rebrand will feel like an impossible lift because nothing is centralised.

That pain is the signal. Build the system when you feel that pain, not before.

Until then, agree on the basics, write them down somewhere everyone can find them, and spend the rest of your time on the product.

The honest version

Most early-stage teams that build design systems are not solving a design problem. They are solving an anxiety problem. The system makes things feel organised and under control at a moment when everything else feels uncertain.

That is understandable. But it is not a good reason to spend six weeks building infrastructure for a product that might pivot next month.

Get your product tight. Make it consistent through discipline, not through tooling. Ship things that work and feel considered.

The system can wait. The product cannot.

I’m Carlos, a product designer running from Porto. I work with startups and founders on products that are worth using. If something here resonated, feel free to connect.