How We Shipped more than 60 Design System Components in 5 Weeks Using Figma as the Single Source of Truth

How We Shipped more than 60 Design System Components in 5 Weeks Using Figma as the Single Source of Truth

We estimated 300 engineer-days. We shipped in 35 days with 3,077 tests and zero raw hex values. Here's the pipeline I built to make Figma the literal source of truth for our codebase.

All front-end developers are familiar with that pain.

A designer drops a Figma file. It is pixel-perfect. All interaction states are included. Next, you launch your editor and the translation process starts.

You squint at 2 screens. What's the gray color of that? Which is 8 pixels and which is 12? What is the font weight for this font? MD_Medium, MD_SemiBold?

The questions are brief. The answers are extremely important. The farther away you are from the Figma file, the more the component deviates from the original idea.

This is not something resulting from carelessness. It's a structural issue; Figma and code are two very distinct ways of representing the same truth, and every time a new engineer has to re-translate the specification by eye.

The cost in real numbers

Our design system had more than 60 components to implement. The effort estimate was conservatively estimated at 4-5 engineer days per component.

That's about 300 engineer-days including design drift at each turn.

The typical failure pattern:

Day 1: engineer reads the Figma spec, guesses what names to give the tokens. Day 2-3: component is written by hand Day 3: QA feedback and it is noted that it is the incorrect color or spacing. Day 4: fixes and review Day 5: tests (if time permits)

After one week, the component continues to drift. The source of truth was a Figma file that was not programmed into the engineer, but looked at.

Why I built Figment

The insight was simple: It was not that engineers failed to be good at reading Figma files. The issue was that they had to read them all.

If it was possible for Figma to talk directly to the codebase, without a human being being an error-prone layer in between?

That became Figment.

The aim was to never take away the human judgment. It does not need to be automated for designers to make decisions regarding hierarchy, intent and emphasis. But the mechanical aspects of the translation, like the exact hex value of a token, the exact measurement of a gap, what font variant equals a particular weight — those answers are there in the Figma file already.

It didn't make any sense for a human to be making the sixty re-answers to the fiftieth time for sixty components.

One of the initial limitations

Every generated component had to use:

Semantic design tokens (not raw hex values) MUI sx props (not external stylesheets) TypeScript strict mode A Storybook story for every meaningful Figma variant Spec-lock tests capable of catching drift in CI

Figment was not built to produce a starting point for an engineer to clean up. It was built to produce code ready for review and ready to ship on the same day.

How Figment works: a three-stage pipeline

Stage 1: Token reconnaissance

Design tokens that are used by the component must exist in the codebase before the component generates them. Stage 1 retrieves the Figma fills for the target node, compares them to the existing token file, and prints a patch that can be pasted to the token file to include the missing tokens. One Figma API call. Thirty seconds. No room for ambiguity.

Stage 2: Token authoring (where all that is necessary is a human touch)

The engineer checks the proposed additions of tokens and adds them to the appropriate semantic group. This is a deliberate manual step as there are design intentions and intents to the token that cannot be captured by automation. The system's state is indicated by a color called surface.pressed, which the hex value doesn't convey.

Stage 3: Deterministic component generation

This is where Figment differs from having an AI create a component from a Figma screenshot.

All values that can be exactly determined are fixed in advance of any data reaching the AI model:

The typography is solved by the algorithm: 12px + weight 500 = MD_Medium, line-height 16px. Injected as facts, not suggestions. The spacing and icon sizes are directly retrieved from Figma's bounding box data. Exact pixels (not rounded up). If all variant dimensions are parsed, then a required coverage block is appended to the input coverage to ensure no interaction state is lost, otherwise the variant coverage is determined.

The output is scanned for forbidden patterns after generating and before writing to disk.

Raw hex values → rejected Numeric border radius with no other modifiers (such as blur or drop shadow) → accepted, but multiplied by 4 (MUI) Missing token imports → rejected There is a problem with the order of the focus rings' shadows.

A file is written only if it passes all the checks. No silent failures.

What a single run produces

Figment creates 3 files when it is called. Not a scaffold. Not at the beginning. A full, reviewed, PR ready package:

The component file containing semantic tokens, MUI sx props and type strict mode

A Storybook story for each meaningful Figma variant.

A spec-lock test to store all the tokens and spacing values for CI checking

All three products are produced simultaneously, all are checked simultaneously and all are sent simultaneously. An engineer's task is to check that it is correct and not rewrite.

Handling intentional deviations from Figma

Not all of a specification should be taken verbatim and pasted into the code. In some cases, the designer may define typography that is applicable to a child component. A spacing value sometimes is more a layout frame artefact than it is a rule for the component itself.

Figment does this using a file called figment.overrides.json that is located with each component. Any deliberate deviation from Figma is documented on a written basis with a justification. Nothing is undocumented. An exact Figma value that is used as a basis for the generated code is recorded in a separate figment.spec.json.

This means that each part has its own origin: what it was said in the Figma file, what it will do differently, and why. A response of 6 months later to "why doesn't this meet the Figma spec?" should not be based on someone's memory, but rather the file.

Automated drift detection in CI with verify-figma

Generating a correct component is one problem. Keeping it correct as the codebase evolves is a separate problem.

A token renamed by a future engineer. A spacing value adjusted without checking Figma. A color swapped in a hurry. These changes silently erode a design system until the code no longer matches the spec.

Figment addresses this with verify-figma, a script that runs on every pull request:

npm run verify-figma -- --component Badge --live --figma-node 397:23320

Typography 12px / weight 500 variant="MD_Medium" PASS Spacing gap in "Icon + Label" 6px PASS Colors raw hex No raw hex values PASS Border-radius 6 checks PASS | 6 passed, 0 warnings, 0 errors

Six checks. Zero warnings. Zero errors. Verified live against the Figma file in thirty seconds.

Pull requests that introduce drift do not merge.

The design system does not rely on the memory or diligence of the people maintaining it. It relies on the Figma file, verified continuously by the pipeline that created it.

The parallel review workflow that made 5 weeks possible

The pipeline was only half of what made this work. The other half was the process design.

Building a design system means satisfying two reviewers: a designer checking visuals and an engineer checking code. Most teams run these sequentially. Three sequential waits per component.

We collapsed them into one:

Run the Figment pipeline for the target component Deploy to Storybook via Chromatic and send the designer a link Simultaneously, raise a PR for engineer code review While both reviews are in flight, start the next component When feedback arrives from both, address it completely

Designer review and engineer review happen concurrently, not consecutively.

We shipped 7 components in a single day using this workflow.

The bottleneck stopped being the build. It became the review queue trying to keep up.

The bottleneck nobody expected

It was not all smooth. Early in the implementation, pull request reviews from the engineer arrived slowly. Components were being generated and deployed. The pipeline was working. But the reviews were not keeping pace with the output.

This is a well-known failure mode on small teams: one person's output rate exceeds another's review rate, and work accumulates in the queue. Components that sit in review for two weeks get feedback in a different mental context than when they were built. Addressing that feedback takes more effort than it should.

Then something shifted. When the engineer's review cadence aligned with the generation rate, the entire dynamic changed. Two people in synchrony: one generating components and running visual review, one reviewing code, both running at the same pace. Components that had been stacking up began shipping daily.

That is the part no tooling can automate. The pipeline can generate at any speed. The workflow can parallelize reviews. But the human rhythm of a team working in sync is what turned a good system into a fast one.

The results

Metric Before Figment After Figment

Time per component 4-5 engineer-days Less than 1 day

Total for 60 components ~300 engineer-days (est.) 35 business days

Tests Written if time allowed 3,077 (every component)

Raw hex values Common Zero

Design drift Discovered weeks later Caught on every PR

Every component has a matching Figma node ID recorded in its source. Every token choice is auditable back to the Figma file. Every intentional deviation from the spec is documented with a written justification in figment.overrides.json.

Why AI alone doesn't solve this problem

I tried using AI tools to generate components from Figma before building Figment. The output was always close but never exact.

The reason: AI tools interpret Figma like a screenshot. They see the design visually and approximate what they see. A 12px font becomes 14px. A 6px gap becomes 8px. A border radius of 6 becomes 8 because MUI multiplies by 4 and the AI doesn't know that.

Figment reads Figma like a database. It uses node IDs to extract exact values from the Figma API. No interpretation. No approximation. Then it resolves every deterministic value algorithmically before the generation model sees any data.

That is the difference between "close enough" and "correct."

What this changed

Before Figment, implementing a component took 4-5 engineer-days. After, the same work took less than a day, with tests included.

The human effort shifted from production to judgment which is precisely where human effort belongs.

A human translating a specification at four in the afternoon makes different choices than the same human on a Tuesday morning. Figment makes the same choices every time.

60 components. 3,077 tests. Zero raw hex values. 5 weeks. One source of truth.

Built by Amrutha Kollu, Software Engineer.