The essentials
A design system only creates value if it survives the trip from Figma to production. That trip is where most of them quietly die. At Brand Appart, we scale design systems for funded startups with a three part stack: Figma as the design reference, Claude Code for the repetitive translation work, and GitHub as the implementation reference the client owns. On the build phase of a website, we estimate this workflow saves around 30 percent of the time, roughly three weeks instead of five, as on the redesign we led for the fintech Incard.
This article walks through the full method: how tokens move from Figma to CSS, what we delegate to AI and what we refuse to, and the one rule that keeps design and code from drifting apart.
What a design system is, and where most of them die
A design system is the shared language between a brand and its product: colors, typography, spacing, components, and the rules for using them. Done well, it means the marketing site, the app and the pitch deck all feel like the same company. Done badly, it is a Figma file nobody opens after month two.
The failure point is rarely the design itself. Studios are good at producing beautiful, coherent libraries. The failure point is the gap between that library and the code that ships. A developer eyeballs a hex value, a spacing token gets rounded to the nearest convenient number, a button is rebuilt slightly differently on a new page. Six months later the product and the brand guidelines are two different things, and the design system has become documentation of what the product used to look like.
So when we talk about scaling a design system, we do not mean adding more components to Figma. We mean making the design to code handoff reliable enough that the system stays true in production, client after client.
The real bottleneck is design to code
Every studio has lived this sequence. The identity is validated. The Figma library is clean. Then the build starts, and the questions pile up: which shade of the primary color is the real one, what does this component do on mobile, why does the shipped card not match the spec.
Handoff is where hours disappear. Not in creative decisions, but in translation: turning design tokens into CSS variables, turning component specs into working front end code, checking that page 14 uses the same radius as page 2. This work is repetitive, cross-cutting and unforgiving. It is also exactly the kind of work that machines now do well, if you frame it correctly.
That framing is the core of our method. We did not automate the design. We automated the translation.
Our stack: Figma, Claude Code, GitHub
Three tools, three distinct jobs. Figma decides what the brand looks like. Claude Code does the repetitive translation and consistency work. GitHub holds what actually ships.
Figma stays the design reference
Everything creative lives in Figma: the identity, the component library, the tokens as designed. When a question is about how something should look, Figma is the answer. No exceptions. This sounds obvious, but making it explicit is what allows the rest of the pipeline to be fast: nobody debates design decisions inside a pull request.
Design tokens: translated, not synced
Here is where our approach differs from most of what you will read about a figma design system pipeline. We do not auto-sync tokens from Figma to code. We translate them into CSS variables and validate them one by one before they land in the repo.
Auto-sync sounds efficient, and plenty of tools promise a live bridge between Figma variables and production CSS. Our problem with it is control. A design system for a brand is not an internal tool; it ships inside a client's product. An unreviewed token change flowing straight into production is a risk we are not willing to take on someone else's brand. Validating each token costs us minutes. Shipping a wrong one to a fintech's live app would cost a lot more.
The one by one validation also forces a useful conversation. Every token gets questioned once: is this a real decision or a leftover, does it deserve a name, where is it used. Systems that go through this filter come out smaller and clearer.
Claude Code handles the cross-cutting work
Claude Code is Anthropic's agentic coding tool, and it changed how we staff a build. We delegate to it the work that is repetitive and spans the whole product.
Generating components from the Figma specs. Once the tokens are validated, Claude Code builds the front end components against them, following the structure we define.
Transforming tokens into CSS. The validated token list becomes clean CSS variables, formatted consistently, without a human retyping hex values at midnight.
Holding coherence across the product. This is the underrated one. Asking a person to verify that every border radius, every spacing step and every text style across forty pages matches the system is a recipe for missed details. Asking Claude Code to sweep the codebase for deviations is a five minute job, and it does not get bored.
Our designers, meanwhile, stay on the work that actually needs them: the identity, the interaction decisions, the taste calls. The honest way to put it: AI did not replace anyone here. It absorbed the part of the job nobody enjoyed, and gave the hours back to design.
An ai design system, in our definition, is not a system designed by AI. It is a system where AI guards the consistency humans decided on.
GitHub is the implementation reference
At the end of a project, the client receives a clean GitHub repo containing three things: their tokens as CSS variables, their components, and the documentation that explains both. Not a zip file, not a Notion page that rots. A versioned repo their developers can build on from day one.
This is also a handover philosophy. A design system you cannot leave behind in usable form is a dependency, not a deliverable. The repo means the client's team can maintain and extend the system without calling us for every button, which is exactly how it should be.
One rule that keeps everything sane
Every pipeline needs a tiebreaker, and ours fits in one sentence: Figma is the design reference, the repo is the implementation reference.
If the question is what the brand should look like, Figma wins. If the question is what is actually running in production, the repo wins. When the two disagree, that disagreement is surfaced and resolved deliberately, through the token validation step, instead of being silently absorbed by whoever touched the file last.
Most design system drift comes from not having this rule. Designers assume Figma is the truth, developers assume the code is, and both are right in their own domain without ever agreeing on the boundary. Write the rule down. It costs nothing and settles arguments before they start.
Scaling across brands without cloning them
There is a trap in the phrase scale a design system when you are a studio: the temptation to reuse the same components, the same type scale, the same visual skeleton across clients, and ship variations of one brand with different logos.
We took the opposite bet. On every new client, the identity is recreated entirely. The colors, the type, the components, the personality: all custom, because that is the job. What we reuse is the method and the tooling. The token validation process, the Claude Code workflows, the repo structure, the documentation format: those are our infrastructure, and they get sharper with every project.
Scale the pipeline, not the style. That distinction is what lets a small studio deliver bespoke systems at a pace that used to require a much bigger team, without every client's product ending up looking like the same website.
If you are weighing what kind of design partner you need for this, you can see how these systems hold up across our recent work.
What it changes in practice
On the build phase of a website, we estimate the gain at around 30 percent: a site built in roughly three weeks instead of five. The Incard redesign ran on this workflow, a fintech project where consistency is not cosmetic. In finance, a product that looks slightly off from its brand reads as untrustworthy, a point we developed in how to build a fintech brand that earns trust.
Here is how the three common approaches to the design to code handoff compare.
The hybrid column allocates trust differently: machines handle volume and repetition, humans handle judgment, and nothing reaches production without a human having decided it should.
Common mistakes when scaling a design system
Four patterns we see repeatedly, and would tell any team to avoid.
Auto-syncing everything. A live pipe from design file to production feels modern until an experimental Figma edit ships to real users. Speed without a validation gate is just faster drift.
Treating the design system as a UI kit. A component library without rules, naming and documentation is a folder of pretty parts. The system is the logic, not the assets.
Writing documentation last. Documentation written after the build documents what happened, not what was decided. We generate and refine docs as the system is built, so the repo the client receives explains itself.
Letting AI make design decisions. Claude Code is excellent at applying a system and terrible at deciding what a brand should feel like, because that is not a computation. Every creative decision in our pipeline has a human name attached to it.
Conclusion
Scaling a design system is not a tooling problem you solve by buying a plugin, and not a craft problem you solve by hiring more hands. It is a pipeline problem. Figma holds the design truth, GitHub holds the implementation truth, and between the two, the repetitive translation work goes to Claude Code while the decisions stay human. Validated tokens, generated components, a repo the client owns: that is the whole method, and it is why our builds got about 30 percent faster without the brands losing what makes them singular.
If you are a funded startup that wants a brand, a product and a website that stay coherent long after launch, tell us about your project.
