When a startup needs a design system

Do startups need a design system before they have a second screen? No. You need one when a second designer, or a second product, would otherwise invent a parallel style. Before that moment, a disciplined Figma file is enough. The file holds the type, the colors, and the components you have actually repeated. It does not need a name, a website, or a roadmap.

The expensive mistake runs in both directions. Teams build a system while one person is still finding the product, and the system freezes a guess. Teams skip it after three people are shipping, and the product quietly becomes two products that share a logo. The timing is the whole question.

The signal that it is time

Watch for a second source of truth.

• A second designer opens a new file because the first one is "messy," and starts a cleaner type scale.
• A second product, or a serious marketing site beside the app, needs buttons and nobody is sure which file is canonical.
• An engineer implements a screen from a screenshot because the Figma styles do not match what shipped last month.
• Two grays, two radii, or two primary buttons show up in review and both have a defender.

Any one of these can be a bad week. Two of them in the same month means the style is no longer in one person's head. That is when a shared system saves more time than it costs. The system, at that point, is still small. It is the decisions you extract from the work you already believe in, written so the next person does not have to ask.

There is a quieter signal inside the code. If pull requests keep arguing about padding and color, the argument has outgrown the ticket. Move the decision into a named value and let the next review check against the name. The argument can return when someone wants to change the name. It should not return on every screen.

What a disciplined file covers until then

While one designer draws the product, the file is the system. Make it behave like one. Text styles, not detached type. Color styles, not eyedropped hex values. Components for anything you have used twice. A cover page that shows the styles so you can see drift without hunting through frames.

Name the styles in words the engineer can reuse. When the file says "body" and the code says "text-base" with no note connecting them, you already have two systems. Pick one vocabulary. On a Hanabi build the code side is React, TypeScript, and Tailwind, and the design side is Figma. The names can differ by syntax. They should not differ by meaning.

Include the decisions that are easy to skip while you are the only author. Focus styles. Error text. An empty state. You will remember them. The next person will invent cheerful alternatives. The W3C's Web Content Accessibility Guidelines frame these as part of making content perceivable and operable. Put a visible focus state and a readable text color in the file now, while there is one file. Retrofitting them across two products is a worse project than drawing them once.

A disciplined file also has a graveyard. When you reject a direction, move it off the working page. Future you, and the contractor you hire in a hurry, will treat every frame on the main page as current. Archive the trials. The working page should look like the product you are willing to ship.

When a second designer arrives

A second designer is the cleanest version of the signal. They are competent, which is the danger. They will improve the spacing, retune the gray, and rebuild the button so it feels more like their last company. None of this is malice. It is what designers do when the rules are implicit.

Before they draw, spend an hour on the file together. Walk the type, the color, the components, and the things you refuse. Ask them to use the styles on a real screen that week. The gaps they hit are the real backlog. A button that cannot be quiet. A table that has no text style for numbers. Those gaps are worth promoting into shared pieces. A desire for a different accent, with no failed screen behind it, can wait.

Give them a way to propose a change that is smaller than a redesign. A note in the file, or a message with a before and after, is enough. You accept it into the styles or you do not. The point is that a change to the shared look is visible. Silent local improvements are how the second file begins.

When a second product appears

A second product is a stronger signal than a second designer, and easier to miss, because it often arrives disguised as a website. The app has a look. The marketing site gets a fresher look, because the founder is tired of the first one. Now you have two. Customers move between them. The mismatch reads as unfinished, even when each piece is polished on its own.

Share the decisions that should survive the trip: type, color, the voice of a button, the idea of how much decoration you allow. Let the surfaces differ in layout. A homepage and a dashboard should not share a grid. They should share a point of view. If you cannot point at one file and say "both of these come from here," you are ready for the small system, not for a larger brand exercise.

Public work at Hanabi shows the range this has to cover without becoming a platform. Wabisabi is a calm brand site. Trade Moai is a trading interface organized for scanning. Those are different densities. A system that forced them into one component kit would be the wrong tool. A system that kept type, color, and restraint recognizable would be the right one. You do not need their files to use the test on your own pair of surfaces.

The cost of building one too early

A system built before the product has settled will encode the wrong decisions with confidence. You will have tokens for a navigation model you abandon, components for a card you no longer use, and a color for a feature that got cut. Maintaining that kit is a tax on every week you should spend learning what the product is.

Early on, change the file directly. Duplicate a frame, try a tighter type scale, throw it away. That freedom is the point of having one author. A formal system is a promise that change goes through a name. Make the promise when breaking it would confuse someone other than you.

If the signal is already here, the next piece shows what the small version contains: a design system for a team of five. It is type, color, space, and a handful of components. It is the size that matches the moment you just reached.

When that moment is now, and you want the file and the code to carry the same decisions, look at Hanabi's services. The studio designs and builds the system with the product, once the product is real enough to deserve one.