Build or buy a design system?

The short answer

Build or buy a design system? Build your own when people on your team have the design system as their main job, and your brand needs things no ready system has. Buy when you need good screens soon, your stack is common, and nobody can spend most of a year on the system itself. Most teams do neither extreme. They buy a base and make it theirs. That third option is where this guide ends.

What a design system contains

A design system is four things that have to stay in step. If one drifts, people stop trusting all of it.

• Tokens: the named values behind every colour, size, space, shadow and duration. A button does not say a hex colour. It says the brand colour.
• Components: buttons, inputs, tables and dialogs, each with every state, drawn in Figma and built in code.
• Accessibility: keyboard use, screen reader roles and colour contrast. Text needs at least 4.5:1 contrast, and graphics that carry meaning need 3:1, in light and in dark.
• Documentation: when to use each part, when not to, and the rules a new teammate needs on day one.

Drawing any of these is the easy part. Keeping Figma, code and docs saying the same thing a year later is the hard part.

What building your own takes, step by step

• Decide the tokens first: colours with a light and a dark version, a type scale, spacing, corner radius, shadow and motion. Name them for what they do (text-default, bg-brand), not for how they look.
• Keep one source of truth. If the same colour is typed by hand in Figma and in CSS, the two will drift. One file that builds both is safer.
• Build components with every state. A button is not one drawing: it has sizes, variants, hover, pressed, focus, disabled and loading, in light and in dark. That is hundreds of variants for one component.
• Name things the same way in Figma and in code. When Figma says variant=brand and React says variant="brand", nobody has to translate.
• Test contrast and keyboard use while you build, and compute the contrast instead of judging by eye. Our first chart palette measured 2.5:1 on white. We replaced it.
• Write the docs when the component is fresh, including when not to use it.
• Name an owner. Someone has to take updates, bug reports and breaking changes. A system with no owner is a snapshot.

In our own source repository, which is not part of the package you install, three commands keep the first two steps honest. The first builds the CSS from the token files. The second fails when the CSS no longer matches. The third fails when a component uses a raw value instead of a token. Buyers get the raw-value check as npx tessera-lint src.

How the same token names reach the Figma variables, and what checks the Figma side, is in how to keep Figma variables and CSS tokens in sync.

npm run tokens        # build the CSS from the token files
npm run tokens:check  # fail if the CSS no longer matches the tokens
npm run tokens:lint   # fail if a component uses a raw value

I have no honest number of weeks for all this. It depends on the team, the number of components and the standard you hold. What I can say is that the drawing is the smaller part. The checks, the docs and the upkeep are what people forget to plan for.

What you keep when you buy

Buying does not mean giving up your brand. It means you do not build the base.

• A base of components that are already built and tested, in Figma and in code, with the same names.
• The accessibility work: roles, keyboard use and contrast, checked in light and in dark.
• Updates and fixes from the maker.
• Your own time, for the parts only your product has.

What you give up is some control. A ready system has opinions about spacing, type and how a component is built. If you fight those opinions every week, it is the wrong system for you.

When building your own is right

• You have people whose main job is the design system, with time for years and not for weeks.
• Your brand needs components that no ready system has, and they make up most of your product.
• Your stack is not React. Tessera is Figma and React only. If you build in Vue or Angular, a React system is the wrong base.
• Rules from your industry or your company have to be built into the controls themselves.

If two or more of these are true, build, or at least plan to. If none are, you are probably about to rebuild a button.

The mixed way: buy a base, then make it yours

Most teams that start from a ready system keep its structure and change the surface. In Tessera the surface is a few choices: brand colour, light or dark, and corner style. You can try them on real components in the Playground before you decide. Colours and sizes are tokens, so a change in one place reaches every component. Getting started shows the steps in React.

• Change tokens, not component code.
• When you need something new, build it from the tokens that already exist.
• Keep your own parts in a separate folder, so an update never overwrites them.

For a worked example of a real screen made from the parts, read the invoice ledger guide.

How to decide in ten minutes

Answer these five questions with your team.

• Do you build in React? If not, build your own or pick another system, because Tessera is React only. Stop here.
• Can someone own the system for at least a year? If not, building is a risk.
• Would most of your components need a new design to match your brand? If yes, building is more likely right.
• Do you need accessible, consistent screens within weeks? If yes, a ready base saves you the most.
• Can you name the three screens you must ship first, for example a table, a form and a dashboard? If yes, check that the system you are looking at already has them.

A no on the first point means build, or pick another system. Otherwise, mostly yes on the fourth and fifth points means buy a base. Yes on the second and third means build. A mix means the mixed way above.

What Tessera gives you, and what it does not

It gives you:

• A Figma file and a React package with the same property names.
• 62 documented React components and nine full example screens built only from the system.
• Three brand themes, each in light and dark, and a Playground to try them.
• Text contrast of at least 4.5:1 in both themes, computed and not guessed.
• One token source: the JSON files build the CSS, and the Figma variables carry the same names.
• 14 base components in a free Figma kit, so you can try the method first.
• Use in unlimited products, commercial or not, all 1.x updates and a 14-day full refund.

It does not give you:

• Support for Vue or Angular. It is React only.
• A finished app or page templates. It is a design system.
• A service contract. One designer makes and maintains it. The terms say it is provided as it is, and reported bugs are fixed in updates.
• A fit for a brand that needs most components redesigned.

See the free kit and the pricing, or read what is in the system.

In the docs

• Introduction
• Getting started