What a design system includes
The phrase "design system" covers a lot, and that is why the build vs buy question is confusing. Before you choose, split it into parts.
- Foundations. Colors, type styles, spacing, radius, shadows, icons. Often stored as design tokens.
- Components. Buttons, inputs, selects, tables, modals, tabs, toasts. Each one with its states: hover, focus, disabled, loading, error.
- Patterns. How components work together, such as a form with validation or a page with filters.
- Code. The components built in your framework, so developers do not rebuild them each time.
- Documentation. Notes on when and how to use each part.
- People and process. Someone who owns it, a way to propose changes, a way to release them.
"Buy" or "build" can apply to each part separately. You can take ready-made code and design your own foundations. You can design everything in Figma and use a library underneath. The real question is how much of this you need to own.
Starting from a library
The fastest start is an existing component library. In the React world there are several well-known ones, such as shadcn/ui, Radix, MUI, Chakra and Mantine, and similar options exist for other frameworks. They differ in approach. Some give you unstyled building blocks that handle behavior and accessibility, and you add the look. Others come fully styled and you adjust the theme.
What you gain:
- Speed. You have working inputs, menus and dialogs on day one.
- Tested behavior. Keyboard handling, focus management and other hard details are already done, usually better than a small team would manage alone.
- A community and documentation.
- Lower cost at the start.
What you give up:
- Your product can look like everyone else's if you only change the colors.
- You depend on someone else's decisions and release schedule. A major update can mean work for you.
- You may fight the library when your design needs something it does not support.
- Your design files and your code can drift apart, unless you keep them in step.
For most small teams, a library is the right base for the code. We will say more about the look below.
Building a starter
A starter sits between a library and a full system. It is a small set of your own decisions, applied to a library or built on a simple base:
- A color set: a brand color, neutrals, and success, warning and error colors.
- Type styles for headings, body and small text.
- Spacing steps and corner radius.
- The ten or so components you use most, designed with all their states.
- The same names for these in Figma and in code.
This is what we include in our MVP design sprint: a design-system starter with colors, type and the key components. It is small on purpose. It gives the product its own look and gives version two a head start, without the cost of a full system.
The advantage is balance. You keep the speed of a library and gain a distinct identity. The cost is that someone must keep the starter in step as the product grows.
A full custom system
A full custom system means designing and building your own components from the ground up, with documentation, versioning and a team that maintains it. Large companies do this, and it can pay off at scale: a distinct look, full control, and consistency across many products and teams.
It also costs a lot, and the cost does not stop. A custom system needs designers and engineers who spend real time on it, a process for changes, and ongoing fixes for accessibility and browser quirks. For a team of five, that time is usually better spent on the product.
A full custom system makes sense when:
- You have several products or teams that must share one look.
- Your brand needs interaction that no library supports.
- You have people whose job is to maintain it.
- You have felt the pain of inconsistency and slow work enough to justify the cost.
If that sounds like a future version of you rather than today, wait.
When to switch
You do not choose once. Teams move along this path as they grow. Signs that it is time to invest more:
- Designers keep redrawing the same component with small differences.
- Developers build the same component more than once.
- Small design changes, like a new brand color, take days across the product.
- New hires cannot tell which component to use.
- You are fighting the library on several screens at once.
- Two or more product teams need to stay consistent.
Signs that you should not invest yet: the product is still changing direction every month, you have only one or two screens, or nobody has time to own the system. A system built too early often needs to be rebuilt.
Cost and upkeep
The real cost of a design system is rarely the first build. It is the care it needs after.
| Option | Up-front effort | Ongoing effort | Main risk |
|---|---|---|---|
| Library only | Low | Low to medium: updates and fixes | Generic look, drift between Figma and code |
| Starter on a library | Low to medium | Medium: someone keeps it current | The starter is neglected as the team grows |
| Full custom system | High | High: needs dedicated people | Spending more time on the system than on the product |
We have left out dollar amounts because they depend on the size of your product and team, and a made-up figure would not help. The comparison that matters is time: how many weeks of whose attention it takes, and who will keep doing it.
Whichever path you take, name an owner. A system with no owner decays. The owner can be a part-time role. It can also be a partner. In our design partner plan, keeping the components in order is one of the things a senior designer can do each month.
Our default advice
For most seed-stage SaaS and AI teams, this is what we suggest:
- Pick a library for the code. Choose one that fits your stack and your team's habits. Favor one with good accessibility.
- Design a small starter on top. Your own colors, type, spacing and key components, in Figma and in code, with the same names.
- Write down the rules you keep repeating. A one-page note is enough at first.
- Grow it when it hurts. Add components when you build them the second time, not before.
- Revisit at each stage. After a big funding round, a second product or a rebrand, ask if the current setup still fits.
This is a default, not a law. If you have an unusual brand or very strong in-house engineering, you may choose differently.
We also build things for ourselves, including a design system, and you can look at them in the Lab. If you want help deciding for your own product, send us your current screens and your stack. We will tell you what we would do, even if the answer is "use a library and spend your budget elsewhere".
