How do we know we are ready for a design system?

The trigger is not size, it is repetition. When two people make the same decision differently and neither is wrong, you are paying for that decision twice every time it comes up. In practice that shows as a new feature needing a full design pass for components that already exist, or two developers building two buttons, or a new designer arriving and introducing a shade of blue that is now permanent. If you have one designer and one product and no plans to add either, you probably do not need this yet.

Does this include the code?

Not by default. The core engagement is the tokens, the components and the documentation in Figma, plus a working session with your engineers to agree how the tokens map into whatever they build in. Building the coded component library — Storybook, a package, tests — is separate work with its own estimate, and bundling it is how these projects end up quoted at half of what they cost.

Will a system slow us down or limit what we can design?

It removes decisions that were never worth making — how tall a button is, what a card border looks like, what the third grey is — so that attention goes to the ones that are. It should never prevent a new pattern. What it does require is that a new pattern gets added to the system rather than living in one designer's file, which is what governance is for and why we spend part of the engagement agreeing how things get added and retired.

How many components will we get?

However many your product actually uses, which the audit tells us and is usually fewer than expected. A tight set that covers the real screens, fully documented, is worth more than a large library with a long tail nobody touches. Component count is one of the two main things that moves the price, so we agree the list before building rather than discovering it.

Can you work with our existing Figma files?

Yes, and that is the normal case. The audit runs on what you have. Files vary a great deal in condition — some already have styles and components, some are frames with hand-nudged spacing — and that condition affects how much of the work is extraction and how much is reconstruction. We look before quoting and tell you which of the two you have.

What happens after handover so it does not rot?

Three things are agreed in writing before the engagement ends — who owns the system, how somebody proposes a change, and how a component gets deprecated without breaking the screens using it. There is also a working session where your team uses the system with us in the room. A system with no named owner drifts back to the old way within a couple of release cycles, and that is a governance failure rather than a design one.

UI/UX & Design

Design system and component library

An audit of what your product actually contains, then tokens, components and documentation that a team will use instead of quietly working around.

From: $2,500–$20,000
Typical time: 4–10 weeks
Usually bought by: Product companies

What this actually solves

The product has grown past the point where one person holds it in their head. There are twenty or forty screens, and each one is slightly different from the others in ways nobody can quite point at. A new feature arrives and the design work starts from nothing again, even though it is made of the same buttons, the same inputs and the same cards as everything else. Two engineers have built two different buttons because there was no third option. A designer joined, introduced their own blue in good faith, and now the product has two.

Individually every one of those is defensible. Collectively they produce a product that looks like it was assembled by several companies, and the person who feels it most is the founder in an investor meeting, scrolling past a screen they had forgotten looked like that.

The second cost is speed, and it is larger. Without a system, every screen is a fresh set of decisions about spacing, weight, radius and colour. With one, those decisions were made once and the team spends its time on the thing that is actually new. The system is not a tidiness project. It is the removal of repeated work.

What we do, and in what order

Audit and count. Every screen in the product screenshotted onto one board, and then an actual count — how many distinct buttons exist, how many blues, how many font sizes, how many corner radii, how many shadows. The number is the first deliverable and it is usually what gets the rest of the work approved, because until somebody counts, nobody in the company knows. Three to five days.
Define the tokens. Colour, type, spacing, radius, elevation, each given a name that describes its job rather than its value. Spacing goes onto a strict scale — 4, 8, 16, 24, 32, 48, 64, 96 and nothing between — because a system whose spacing is negotiable is not a system. Type goes onto a fixed ladder rather than a per-screen decision. Three to five days.
Build the components. Every variant and every state, not just the default one. A button is primary, secondary and ghost; small, medium and large; default, hover, pressed, disabled and loading. The states are where the work is and where systems are usually thin, because the default is the easy one. Two to four weeks.
Write the documentation. For each component — what it is for, which variant to use when with a real example, when not to use it, the rules for writing its label, keyboard and screen-reader behaviour, contrast requirements, and the mistakes people commonly make with it. The negative cases are the half that makes documentation get followed. One to two weeks.
Agree the mapping into code. A working session with your engineers on how tokens become variables in their stack, what the component names are on both sides, and what the migration order is for existing screens. Two to three days.
Hand over and teach it. A session where your team builds something with the system while we watch, which surfaces the gaps that reading the docs never does. Plus the governance agreement — owner, contribution route, deprecation route. Half a day.

Built in Figma using variables, components and variants, documented in Figma or Notion, with Dev Mode for handover.

What moves the price

The range is $2,500–$20,000, the widest in this category, and three things decide it.

How many components. Fifteen components covering a focused product sits near the bottom of the range. Fifty covering a mature multi-surface application sits near the top, and the difference is mostly states and variants rather than the components themselves.

Whether coded components are included. Figma-only is one engagement. Figma plus a built and documented library your engineers install is a substantially larger one, and it is estimated separately rather than assumed.

Whether training and governance are included. A system delivered as files is cheaper. A system delivered with a working session, an owner and an agreed contribution process costs more and is the version that is still in use a year later.

What usually goes wrong

Seventy components and no documentation. It is the most common failure and it looks like diligence while it is happening. Fifteen of the seventy are never used by anyone, the documentation is left for later, and later does not arrive. The team cannot tell which component to use so they build their own, and the library becomes a museum. A small documented system that people use beats a large undocumented one by a distance that is hard to overstate.

No when-not-to-use section. Documentation that only describes what a component is for produces a primary button on every row of a table, a destructive red used for emphasis, and a modal for something that should have been a page. People are not being careless — they were told what it is for and nothing else. Every component doc here carries the negative case and the label-writing rules for that reason.

The system ships and the existing screens do not move. Tokens are defined, components are built, and the forty screens already in production still carry the old values. The product now contains two systems instead of one and the count you started with has gone up. The audit therefore ends in a ranked migration list — which screens move first, which are scheduled, and which are deliberately left alone until they are next touched.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

How do we know we are ready for a design system?: The trigger is not size, it is repetition. When two people make the same decision differently and neither is wrong, you are paying for that decision twice every time it comes up. In practice that shows as a new feature needing a full design pass for components that already exist, or two developers building two buttons, or a new designer arriving and introducing a shade of blue that is now permanent. If you have one designer and one product and no plans to add either, you probably do not need this yet.
Does this include the code?: Not by default. The core engagement is the tokens, the components and the documentation in Figma, plus a working session with your engineers to agree how the tokens map into whatever they build in. Building the coded component library — Storybook, a package, tests — is separate work with its own estimate, and bundling it is how these projects end up quoted at half of what they cost.
Will a system slow us down or limit what we can design?: It removes decisions that were never worth making — how tall a button is, what a card border looks like, what the third grey is — so that attention goes to the ones that are. It should never prevent a new pattern. What it does require is that a new pattern gets added to the system rather than living in one designer's file, which is what governance is for and why we spend part of the engagement agreeing how things get added and retired.
How many components will we get?: However many your product actually uses, which the audit tells us and is usually fewer than expected. A tight set that covers the real screens, fully documented, is worth more than a large library with a long tail nobody touches. Component count is one of the two main things that moves the price, so we agree the list before building rather than discovering it.
Can you work with our existing Figma files?: Yes, and that is the normal case. The audit runs on what you have. Files vary a great deal in condition — some already have styles and components, some are frames with hand-nudged spacing — and that condition affects how much of the work is extraction and how much is reconstruction. We look before quoting and tell you which of the two you have.
What happens after handover so it does not rot?: Three things are agreed in writing before the engagement ends — who owns the system, how somebody proposes a change, and how a component gets deprecated without breaking the screens using it. There is also a working session where your team uses the system with us in the room. A system with no named owner drifts back to the old way within a couple of release cycles, and that is a governance failure rather than a design one.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Design system / component library All UI/UX & Design services