Design systems

Decisions your developers can install.

Tokens, components and documentation that live in the same language as your codebase, so the colour in the design file and the colour in production are the same colour for longer than a week.

Start a projectSee pricing

The problem

Drift is a process problem, not a discipline problem.

Every team that builds software ends up with eleven shades of grey and four button heights. It happens because each new screen is built by someone under time pressure who cannot find the existing component, so they make a near-copy. Do that fifty times and the interface stops feeling like one product.

Telling people to be more careful does not fix it. Making the correct component the fastest thing to reach does. That is the whole idea behind a system: reduce the number of decisions anyone has to make per screen to almost none.

It only works if the system is small enough to learn in an afternoon and specific enough to answer real questions. A hundred components nobody has read is worse than twenty that everyone uses.

“Design hands over a file, engineering builds something close to it, and three sprints later nothing matches. Nobody is doing anything wrong.”

A head of product, describing the usual failure

What you get

Everything in the box.

Built against your actual product, not a demo. We work from your live screens and your existing code conventions.

  • A token set for colour, type, spacing, radius, shadow and motion, exported as CSS custom properties and JSON.
  • Semantic naming: tokens describe the job, not the value, so a theme change does not require a find and replace.
  • A component library covering buttons, inputs, selects, cards, tables, modals, alerts and empty states.
  • Every component specified in all its states: default, hover, focus, active, disabled, loading and error.
  • Contrast checked across each surface the components sit on, with the ratios recorded.
  • Responsive rules at your chosen breakpoints, written as behaviour rather than as pixel pinning.
  • Documentation with a usage note and a plain explanation of when not to use each component.
  • A contribution guide covering how a new component gets proposed, reviewed and added.

How it runs

Four steps, start to handover.

  1. Inventory

    We screenshot every unique interface element in your product and count the duplicates. The number is always higher than anyone expects.

  2. Define

    Tokens and naming agreed with engineering before anything is drawn, because names are the part that is expensive to change later.

  3. Build

    Components built, specified state by state, and checked against the awkward screens rather than the tidy ones.

  4. Adopt

    A working session with your team, a migration order that starts with the highest-traffic screens, and the contribution guide.

Price

From ₹2,40,000

Six to eight weeks, depending on how many screens exist.

Priced against the size of the existing product. A single-app system sits at the starting number; multi-product and multi-brand setups are quoted separately.

Get a fixed quote

Questions

What teams ask before booking.

Do you build the code, or just the design files?

Design files, tokens in CSS and JSON, and specifications precise enough to build from without asking follow-up questions. We can build the front-end components too, quoted separately, but most teams prefer their own engineers to own that layer.

We use a component framework already. Does that change things?

It helps. If you are on an established framework, the system layers on top as a theme and a set of usage rules rather than a rebuild, which is a much cheaper project.

How do we stop it going stale?

One named owner and a contribution route. Systems die when nobody is allowed to add to them, so people work around them instead. The contribution guide is not an afterthought; it is the part that decides whether this is still in use in two years.

Can this be done before we have a brand identity?

It can, but it will encode decisions that may later change. If identity work is likely within six months, do that first and save yourself a retrofit.

What about dark mode?

Semantic tokens make dark mode a second value set rather than a second design. We include the structure for it as standard and can build the full dark theme as an add-on.

Also relevant

Two services that sit next to this one.

Related service

Brand identity

We decide the mark, the palette, the type and the rules once, apply them to the things you actually send out, and write down why each decision was made so the next person can follow it..

Related service

Landing pages

Designed and built in hand-written HTML and CSS.

All services

How many greys are in your product?

Send us three screens and we will count them, tell you what the drift is costing in build time, and scope the smallest system that stops it.

Start a project