The conventional wisdom is that design systems are an enterprise concern — something to invest in once you have ten designers and twenty engineers. We disagree. The compounding cost of building without a design system kicks in around the third feature, not the thirtieth, and retrofitting one later costs far more than starting with one.
What "design system on day one" actually means
It does not mean a Storybook with 200 components and a separate design-ops team. It means:
- 10–15 base components (button, input, card, modal, toast, table) with documented variants and states.
- Design tokens — colours, typography, spacing, radius — defined once and consumed by both Figma and code.
- Two Figma libraries at most: foundations (tokens) and components.
- One Storybook that engineers can open to see what already exists.
For a small team this is typically a sprint's worth of work shared between design and engineering, not a quarter-long programme.
The cost of not doing it
By feature five, you have three different button styles, four spacing scales, two typography hierarchies, and a UI that increasingly feels patched together. The cost of fixing it grows with every screen you ship. The cost of starting over is high enough that most teams just accept the inconsistency, and it shows in their product.
The hidden costs are just as real: code reviews that debate spacing instead of logic, accessibility that varies from screen to screen (some buttons have focus states, some don't), and new engineers who rebuild components because they cannot find the existing ones.
The starter kit, component by component
| Component | Variants and states to define on day one |
|---|---|
| Button | Primary, secondary, destructive, ghost; default, hover, focus, disabled, loading |
| Input | Text, number, textarea, select; default, focus, error, disabled, with help text |
| Card | Static and interactive; with and without header and footer |
| Modal | Small and large; focus trapping, escape to close, a clear primary action |
| Toast | Success, error, info; rules for auto-dismiss and stacking |
| Table | Sorting, empty state, loading state, row actions |
The states matter more than the variants. Most inconsistency creeps in through the error, empty and loading states that nobody designed.
Tokens that compose well
The single most important decision is your token shape. Use semantic names, not raw values:
--color-text-primary, not--color-gray-900.--space-2, not--space-8px.--radius-card, not--radius-12.
Semantic tokens let you change the underlying value without renaming everything downstream. Dark mode is the classic test: with semantic tokens it is largely a second set of values; with hard-coded colours it means touching every component.
A three-tier structure works for most startups:
- Primitive tokens — the raw palette and scales, such as
--gray-900or--blue-600. Referenced only by other tokens. - Semantic tokens — meaning, such as
--color-surface-raisedor--color-border-danger. Used by components. - Component tokens, only where needed — for example
--button-primary-bg, for the few places a component must diverge.
Figma and code, sharing one source of truth
Style Dictionary, Tokens Studio or a small homegrown script — pick one and run it on every change. Figma variables flowing through to CSS custom properties (or a Tailwind config) is the difference between a design system that drifts and one that holds. The Design Tokens Community Group format is worth adopting for the token files, because it keeps you free to change tools later. A simple flow:
- A designer updates a variable in Figma.
- The token JSON is exported and opened as a pull request.
- CI builds the CSS variables or Tailwind config and publishes a Storybook preview.
- An engineer and a designer review the preview and merge.
Keeping it alive without a design-ops team
- Name one owner, a designer or front-end engineer, with an hour or two a week for requests.
- Adopt a rule: new UI uses existing components, and anything missing is added to the system first.
- Add a lint rule or review check against raw hex and pixel values in product code.
- Run visual tests in Storybook on each pull request so changes to a shared component are visible before they ship.
- Build accessibility in at component level: focus states, labels and contrast fixed once are fixed everywhere.
FAQ
We are three features in. Is it too late?
No. Start with tokens, then replace the most-used components, usually buttons and inputs, first. Retrofit screens as you touch them rather than in one big rewrite.
Do we need a dedicated designer to run it?
Not at the start. A front-end engineer with a good eye can own tokens and components, with a designer reviewing changes. What matters is that one person is accountable for saying yes or no to new variants.
Should we start from an off-the-shelf component library?
Often, yes. A headless or themeable library can supply your base components; your tokens and documented variants are what make it your system.
How we set this up at Velura Labs
Our Product Design & UX sprint includes this lightweight design-system foundation, even on a one-off project, and the tokens flow into the codebase through our Web App Development or Mobile App Development builds. Read our Bharat design patterns for the user-facing decisions that pair well with this. Talk to us if you're three features in and your UI is starting to look patched together.
Available to businesses across the United States (Washington, California, Texas, New York), Europe (France, Italy and the wider EU), the Middle East (Dubai and the Gulf) and India. Get in touch to scope your build.