What's the difference between a component library and a design system?

The library is the parts inventory — buttons, inputs, cards. A design system wraps it with tokens, usage guidance, and governance. You can have a library without a system; a system without a library is just a document.

Should a startup build components from scratch or on an existing library?

Build on proven primitives (accessibility is hard to get right) but own the visual layer — wrap them under your own API and styling so the product doesn't look like a template and swaps stay cheap.

Component Library

A collection of reusable, pre-built UI elements — buttons, inputs, cards, modals — shared across a product to speed up and standardize design.

Deliverables & Artifacts

A component library is the reusable-parts inventory of a product: every button, form field, menu, and card built once and used everywhere. It exists in both the design tool (for designers) and the codebase (for engineers), ideally kept in lockstep so a component looks and behaves the same in Figma and in production.

It is the most tangible piece of a design system — the system also carries tokens, guidelines, and governance. On its own, a component library already pays off by eliminating redraw-from-scratch work and the subtle inconsistencies that creep in when every screen reinvents the same elements.

In practice

An audit of a three-year-old SaaS product finds fourteen button variants, five modals, and three different date pickers — each a past deadline's shortcut. Consolidating into a documented library of four buttons, one modal, and one picker takes a quarter of gradual migration. The payoff shows up quietly: a new designer ships their first production screen in days, and “which button do we use?” disappears from reviews entirely.

Component Library

In practice

Frequently Asked Questions