← Work

Tooling · AI delivery · Personal setup · 2026

Code to Figma with MCP

I had a working prototype and no design file. I connected Claude Code to Figma through MCP, then had it read the codebase and write the design system and key screens into Figma.

Role
Set it up, and I design in it
Connected
Figma MCP · Vercel MCP
Generated
17 components · 35 variants · 6 screens
Source
NZ Investment Tracker codebase
Output
Figma design system + key screens

The situation

I built the NZ Investment Tracker prototype with AI, in code, without drawing it first. That is fast, and it leaves you stuck: the product exists and it is consistent, but none of that consistency is written down anywhere a designer can open.

Every colour, spacing step and component variant was a decision I had made. They were just living in a codebase rather than in a file I could ideate in.

The design system already existed. It was just written in the wrong language.

What I set up

Claude Code can work inside other software through MCP. It is a standard connection that lets an AI assistant read and change real files, instead of only describing what it would do. I connected two servers. Figma is the one this page is mostly about. Vercel does the other end: it deploys what I have built to a live URL from the same session, so someone else can open and try it without me stopping to run a release.

With Figma connected, I asked Claude Code to read the prototype's code, work out the design system implied by it, and write that into a Figma file with the key screens. Not screenshots in a frame. Real styles and components I can pull from.

How it runs

CODEBASECLAUDE CODEFIGMAstyles, componentsback by handWorking prototypeThe Investment Tracker, builtin code first with no designfile behind it.Read the codeColours, spacing, type stylesand repeated components, asused.Derive the systemThe implied rules, named andmade consistent rather thaninvented.Write the Figma fileStyles, components and the keyscreens, through the Figma MCPserver.Ideate from itSomewhere to draw the nextscreen that is not a codeeditor.
The dashed edge matters. Generating the system from code is automated; putting a design change back into the code is still a step I take by hand, which is the right way round for anything that ships.
MCP
Model Context Protocol. A common way for an AI assistant to connect to real software, so it can read and change things in that software instead of only describing what it would do.
MCP server
The connector for one specific tool. The Figma one lets an assistant read and write Figma files; the Vercel one lets it work with deployments.
Design system
The named set of colours, type styles, spacing and components a product is built from, so twenty screens look like one product.
Component
A reusable piece of interface, such as a card or a button, defined once and used in many places.

What came out of it

  1. 01

    17 components

    Seven variant sets and ten singles: button, choice row, stat tile, confidence meter, banner, chip and input, alongside the pieces that only ever exist once.

  2. 02

    35 variants

    Button carries eight on its own, four styles across two sizes. Choice row carries four, radio and check in default and selected.

  3. 03

    6 screens at 375px

    Two onboarding steps, the three views, and the add entry sheet. Assembled from the components rather than drawn.

  4. 04

    29 colour tokens

    Each bound to a dark and a light mode, so 58 values. Four surface, three ink, two line, three accent, nine status, six series and two static.

Why do it this way

Building in code first is quicker for a solo project, and the usual price is that you end up unable to design any further. You cannot sketch a new screen against a system that only exists as class names.

This closes that gap. The system comes out of what was built, not out of what I meant to build, which is what makes it accurate. It documents the product that exists, not a tidy version nobody shipped.