From Figma to Front-End Without Losing Your Mind

F

This is Part 1 of a three-part series on building the Prerender.io Design System, a front-end foundation built with Claude Code and Figma, designed to serve as a single source of truth across all Prerender.io products.
Part 2: Building the Prerender.io Design System, Wave by Wave
Part 3: What Collaborating with an AI Dev Actually Taught Me (coming soon)


Figma UI Kit open alongside Claude Code, the actual working setup.

For quite some time now I’ve been chasing the same idea. Design something in Figma, push it to the front-end, iterate, push back. A clean loop. No context lost in translation. No “it looked different in Figma” conversations.

Simple enough in theory: a bit of a nightmare in practice.

The bigger challenge underneath it was this: I wanted a single source of truth for the front-end layer. One place where colours, typography, spacing, components and layout logic all live, and every project you spin up pulls from that same foundation.

What tools did I try first?

Let me be honest about what didn’t work, because I think it saves people time.

A quick overview of the tools evaluated and where each one fell short for this use case.

UXPilot is great for quick pitches and early-stage mockups. You can get something presentable in minutes. But ask it to respect a real Design System: it doesn’t really get there. The output lands in Figma but usually is far from the intended look.

Figma Make kept me inside Figma, which is both its biggest selling point and its biggest limitation. It always generates React by default, regardless of your actual stack. And… everything stays inside Figma’s world. The moment you try to take those components somewhere real, you’re on your own.

Lovable I haven’t fully explored, but from the outside it’s clear the ecosystem is built to keep you inside it. Not a criticism, that’s a legitimate business model. It’s just not compatible with having a portable, project-agnostic front-end.

Builder.io was the one I had most hope for. I ran a few tests. The standard licence doesn’t include Design System integration. You’d need to go Enterprise tier for that. If the feature is buried that deep in the pricing, I find it hard to trust it’s really there. I moved on.

What was I actually looking for?

None of those tools failed because they’re bad. They failed because my use case was more demanding than “generate a screen that looks like this.” I’m past that stage.

What I needed was infrastructure. Take the Figma component library, extract its design tokens and visual patterns, turn that into a real front-end Design System installable as a dependency. And then use it as the foundation for every product we build.

Landing on Claude Code

After all those tests, I ended up with a combination that works: Claude Code + the Figma MCP plugin + Figma. The basic loop: pull design context from Figma using get_design_context, build the UI in Claude Code, push to git, deploy.

What makes this different from everything else is what it doesn’t do. It doesn’t lock you into a platform. It doesn’t hide your own Design System behind an Enterprise paywall. It runs locally. The output is just code, regular TypeScript React components that you own completely.

The tradeoff is that you do more of the thinking. For design system work, that’s exactly where the thinking should be.

The Prerender.io approach

For the Prerender.io Design System, the workflow was: generate the DS from the Figma component library first, then use that DS as the foundation when building actual product screens. Claude doesn’t invent new patterns (well it does sometimes, but you can ground it back to the original library) it uses what the system already provides.

The result feels like a product, not a collection of generated screens that happen to look similar. That distinction matters more than it sounds.


The tools I tested weren’t bad; they were solving a different problem. Most UI generation tools stop at visual translation: output that looks like the design. What I needed was a shared foundation that the design and the front-end both draw from. That’s a different requirement, and it rules out most of the market. It also rules out anything with serious lock-in: the fastest tools to start tend to have the steepest exit, and running locally while owning your output is worth the extra setup. And when it came to the actual build, starting from Ant Design v5 and layering Prerender’s tokens on top was consistently faster and cleaner than asking Claude to build a custom system from scratch. An existing foundation beats a blank canvas.


Next: how the actual build went, wave by wave, component by component, and what surprised me.

About the author

Lucas

UX Lead and AI Transformation Consultant
20+ years shaping B2B SaaS and digital products. Focused on AI-powered design, scalable UX, and turning complex business needs into simple, high-impact user experiences.

By Lucas