Service · Software development

Custom design system development for multiple product teams.

A single source of truth for your colours, typography, components and interaction patterns. Available in Figma and as a code library, documented in Storybook, and designed to be used by several teams at once without falling apart.

Design tokensComponent libraryStorybookMulti-brand themes

Arrange an introductory call See our work

A design system is not a UI kit with a fancy name.

A UI kit is a collection of Figma components. It looks good, but once several product teams start using it, it drifts apart: colours diverge, spacing no longer matches, buttons are reinvented over and over, accessibility erodes team by team, and nobody knows which version is live where. The Figma file grows steadily less in sync with what appears on screen.

A genuine design system links design and code through tokens, delivers a versioned component library, documents decisions in Storybook, and has governance in place so the system doesn't stagnate after a few releases. We build this for scale-ups with multiple product teams, enterprises with a multi-product portfolio, and organisations that want to roll out a design system across multiple web applications.

The biggest promise is not visual consistency; that is a welcome by-product. The real promise is speed: a team building a new page reaches for existing, validated components and delivers in days what would take weeks without a system. Accessibility is done properly once and then inherited everywhere. A rebrand becomes a token change rather than a project per application.

Three roles we step into.

Not every project starts from scratch. Sometimes there's already a Figma library, sometimes only a brand refresh is needed, and sometimes an existing system has to scale across multiple brands. We adapt our role to where you are.

Greenfield · built from scratch

Building a new design system

You're somewhere mid-scale-up, with two or three product teams each inventing their own UI, and you now want one system that works everywhere. Together with your design team (or our design partner), we lay the foundation: tokens, base components, Storybook, and a first release for pilot teams.

Design tokensComponent libraryStorybooknpm package

Migration · from CSS frameworks to tokens

Renewing an existing system

You have a legacy stylesheet, a Bootstrap fork from earlier years, or a Figma library that no longer reflects what's in production. We migrate step by step to a token-based system, maintain backwards compatibility where needed, and deliver codemods so your teams can swap old components for new ones.

Style DictionaryTokens StudioCodemodsDeprecation paths

Multi-tenant · white-label themes

Theming for multiple brands

You deliver a platform to customers who want to offer it in their own brand identity, or you have a brand portfolio with multiple labels on the same codebase. We make the design system themeable: tokens can be overridden per tenant, components adapt accordingly, and your customers can apply their own colours, typography and logo through a config. A good fit for a multi-tenant platform.

Theme tokensBrand overridesRuntime themingTenant config

What's included in a design system.

The concrete deliverables — not a marketing layer, but the building blocks your teams work with every day. Below are the standard components we build or help build, depending on where you are. Not every project needs everything in the same depth: an organisation with one product team needs less governance than an enterprise with fifteen teams and three brands.

Design tokensColour, typography, spacing, shadow, radius, motion curves — stored as JSON/YAML and published as CSS variables, JS objects and Figma variables via Style Dictionary or Tokens Studio.
Component libraryReusable UI components: button, input, modal, dropdown, navigation, data table, form controls, toast, tabs. In Figma as instances and in code as framework components.
Code implementationReact, Vue, Angular or Web Components — depending on your stack. Published as an npm package (public or via a private registry) with semver versioning.
Storybook documentationEvery component with do/don't guidance, props table, accessibility notes, usage patterns and code snippets. At the same time, the playground where designers and developers experiment.
Built-in accessibilityWCAG AA as the baseline, AAA where feasible. Keyboard navigation, screen reader labels, visible focus states, sufficient contrast — tested with axe and Playwright, not bolted on afterwards.
Theming layerTokens overridable per brand, tenant or mode (light/dark/high-contrast). The component code stays the same; only the tokens change.
Versioning & migration guidesSemver, a planned deprecation path for components being phased out, and written migration notes with every major release so product teams know what to adjust.
Adoption toolingESLint rules that flag deviations, a dashboard showing which team runs which version, and visual regression tests via Chromatic that prevent components from shifting unnoticed.
Governance modelA workable contribution model (who may contribute, who reviews, how an RFC is submitted) so the system stays alive rather than freezing after the first release.

When a design system pays off.

Not every organisation needs one. Below a certain scale, a simple UI library is sufficient. Below are the patterns in which a proper design system pays for itself quickly.

Scale

Multiple product teams

You have two or more product teams each working on their own screens. Without a shared foundation, things become inconsistent: different buttons, different modals, different form states. A design system makes copying between teams legitimate instead of a source of bugs.

Multi-product

Portfolio of multiple apps

You deliver several applications that fall under the same brand for your customers. A user switching between your apps should not have to relearn a different navigation or different form conventions.

Rebrand

Rebrand plus scaling

You are going through a rebrand or an M&A integration in which two brands come together. A tokens-based system means the visual rebrand only has to happen once, rather than per application.

White-label

SaaS with customer themes

You provide software that customers want to offer in their own house style to their own users. A theming layer is then not an option but a core feature. See also multi-tenant platform and enterprise software projects.

How such a project runs.

Inventory & baseline

We map out what already exists: existing Figma files, production screenshots, CSS archaeology, conventions per team. This is followed by an audit of the pain points the system must solve — often: inconsistent buttons, inaccessible form states, colour chaos, no single source of truth.

Token architecture & core components

We define the token layer (colour, type, spacing, motion) and the first layer of components: button, input, label, link, card, modal. These go straight into Figma and into code so that designers and developers can work in parallel. We deliberately choose a three-layer token architecture (primitive, semantic, component) so that a rebrand later becomes a matter of adjusting the semantic layer rather than redrawing every component.

Storybook & first release

Documentation is written from the start. Not as post-launch chore work, but as a living spec: no merge without a Storybook page. The first npm release is a 0.x version for the pilot teams.

Pilot with one team

One product team goes live with v0.x. We keep it deliberately small: the team provides feedback, we iterate, and only then do we roll out. This prevents us from delivering an elegant system that doesn't fit real screens in practice.

Adoption roll-out

Wider rollout to the other teams. Support through weekly office hours, a Slack channel where teams can ask questions directly, codemods for migration, and linters that flag deviations (off-system colour values, hardcoded spacing, use of legacy components). We monitor which team runs which version: adoption is measurable, not assumed. A dashboard shows live how far the roll-out has progressed and where drift appears.

Governance & ongoing development

The system is a living thing. New components are contributed through an RFC process, breaking changes follow semver-major, and we monitor visual regressions with every release. Optionally we remain involved as maintainer, or we hand it over entirely to your internal team.

Frequently asked questions.

What clients usually want to know before starting a design system project.

What is the difference between a UI kit and a design system?

A UI kit is a Figma file with components. Nice to look at, but it is only design: there's no code alongside it and no documentation beneath it. A design system is design and code, connected through tokens, documented in Storybook, versioned via npm and governed by a clear model. The difference is practical: a UI kit shows how something could look, a design system ensures it works that way in production, and keeps working when three teams are pulling on it at the same time.

We have our own design team — will you work with them?

Yes, usually. In greenfield projects our engineering team works alongside your design team. We translate Figma into tokens and code, while your team remains the final authority on visual direction and brand decisions. Where you don't yet have design capacity, we bring in a dedicated design partner. We don't design endless marketing styles ourselves, but we make sure the design results in a working code system. We agree the division of roles clearly up front: who designs which component, who reviews accessibility, and who has the final say on a token choice.

Can you only build the code library if we already have the design?

That's a common starting point. You have Figma components but no versioned code library yet. We then implement the components in your framework (React, Vue, Angular or Web Components), publish them as an npm package, set up Storybook and build the adoption tooling. The design belongs to you; the working code implementation is ours.

How do you handle accessibility?

Accessibility is built in from the start, not left to a final check sprint. In practice that means: WCAG AA as the baseline (AAA for the public sector where required), keyboard navigation and focus states on every interactive component, screen reader labels via ARIA, sufficient colour contrast in every token, and automated axe tests in Storybook. Where contractual requirements apply, we deliver a per-component WCAG conformance report so you can demonstrate to clients or regulators that the basics are in order. For healthcare and government contracts where accessibility is a hard requirement, we align the testing package with the European Accessibility Act and NEN standard requirements.

Does this also work for multi-tenant or white-label setups?

Yes, that's actually a common use case. We build a theming layer in which tokens can be overridden per tenant or brand: colour, typography, logo and spacing can be set per client via a config file or runtime API. The component code stays the same; only the tokens change. It fits well with a multi-tenant platform or a SaaS portfolio offered to customers under different brands.

What determines the cost of a design system project?

The main variables are: the scope of the component library (10 basic components versus 60 including a data table and form builder), the number of frameworks that need support (React only, or also Vue and Web Components), the degree of theming (one brand or multi-tenant), and the amount of migration work in existing applications. We work with fixed sprint budgets so you can steer, sprint by sprint, where the time goes.

How long before the system is usable?

A first usable release (tokens, 8–12 basic components and Storybook) is ready after a few sprints and can then be used by a pilot team. The complete system, with all components, theming and adoption tooling, is a multi-sprint project. We usually work on this in parallel with the pilot, so the system grows step by step with input from practice.

What if our system stalls again after a year?

That is the most common problem with design systems: after the initial release, nobody makes time to review contributions, and the system gradually falls into disuse. Components get "quickly copied and adapted" locally, drift accumulates and the central system falls behind practice. For this reason we always build in a governance model: a clear contribution path, RFCs for larger changes, a review board with both design and engineering representation, and adoption metrics so you can see which team is on which version. Optionally we stay involved as maintainer, or we train your internal team to take it over, which fits well alongside a broader platform development effort.

Which tools and frameworks do you use?

Vendor-neutral: Figma for design (Sketch only for legacy work), Style Dictionary with Tokens Studio for the token pipeline, Storybook for documentation, React with Radix primitives or Headless UI where the framework choice allows it, and Vue 3 or Web Components where the stack calls for them. For distribution we use npm or a private registry (GitHub Packages, JFrog), Chromatic for visual regression and Playwright for interaction tests. We choose based on your stack, not on a fixed favourite.

Talk to us about your design system.

A no-obligation half-hour introduction. We listen to where you stand, whether that's an existing Figma library, a rebrand, a multi-product portfolio or a clean slate, and give you an honest picture of what a suitable project involves. We discuss what is realistic for your scale, which parts you already have in-house and where we step in, and the risks that typically come up in design system projects. If it sits naturally alongside a headless CMS project or a broader platform renewal, we'll point that out too.

Book an introductory call Or see our work