When to build a design system: a two-year startup diary and the product trade-offs

Design · 6 min read

At launch, NovaCart used a lightweight component library and relied on engineers to copy-and-paste styles. Within 12 months, inconsistent UI patterns, rising QA time, and brand drift became visible. The product team weighed three options: continue ad-hoc components, appoint a small token-based system, or build a full design system with documentation and governance.

They started with tokens and a few canonical components (buttons, inputs, cards), pairing designers with front-end engineers to ship a versioned npm package. In year two, adoption metrics (components consumed per repo) and reduced regression tickets justified expanding to a living documentation site and a contributor guide. Governance remained light: a monthly triage meeting and a triaged roadmap for new primitives.

Results included a 35% reduction in UI bugs tied to inconsistent spacing and a 20% faster feature cycle for product teams using the system. The diary emphasizes that timing matters: invest when you have multiple products or more than five active UI engineers, and keep governance pragmatic so the system becomes an enablement tool rather than a bottleneck.