My Figma to Next.js workflow, as a designer who ships

I design in Figma and build in Next.js. This site, a bill splitting app, a mosque's accounts app and a shop's billing system all went from Figma to a live Next.js app the same way. This is that workflow, step by step, plus the tools I use as an indie app builder.

It isn't a plugin that turns frames into code. I've tried those, and the code they make is hard to change. This is a way of working where the design and the code agree from the start.

1. Design the system before the screens

Before any real screen, I set up a small set of choices in Figma as variables: a handful of colours, a type scale, spacing, and corner radii. On this site that's a near-black background, warm white text in three strengths, a hairline colour, and one lime accent. That's it.

Fewer choices make the hand-over to code almost mechanical. If a screen needs a colour that isn't in the set, that's a design question to answer, not a hex code to sneak in.

2. Turn those choices into code first

The first file I write is the design tokens. With Tailwind CSS v4, they live in CSS: plain variables, mapped to Tailwind names so I can write bg-bg or text-accent in components.

:root {
  --bg: #0c0c0a;
  --text: #f3f2ec;
  --text-2: #a3a29a;
  --accent: #d4ff3a;
}

@theme inline {
  --color-bg: var(--bg);
  --color-text: var(--text);
  --color-text-2: var(--text-2);
  --color-accent: var(--accent);
}

Now the Figma variable called accent and the class called text-accent are the same thing. Change it in one place and the whole site follows. Fonts go in the same way, through next/font, so they're self-hosted and don't flash on load.

3. Build components, not pages

Next, I build the pieces that repeat: the header, a section title, a card, a button. In Figma they're components. In code they're React components with the same names. Pages are then mostly assembling pieces that already exist.

I keep components plain on purpose. A Container that sets the page width. A SectionTitle with a label and a big heading. When the design and the code use the same few building blocks, a change in Figma maps to one change in code.

4. Real content, as early as possible

Lorem ipsum hides problems. A real project name that's twice as long as the mockup's, a real price with four digits, a real screenshot that's darker than you thought. I move real content in on day one, even if it's rough, and keep it in simple data files so it's easy to edit later.

5. Build with an AI pair, but read every change

I build with Claude Code. I describe the screen, point it at the design and the existing components, and it writes a first version. Then I read the change before it goes anywhere. AI is fast at the boring parts. It's also happy to invent a new colour, skip an empty state or forget about keyboard users. A designer's eye still has to be the filter.

The real win is speed of iteration. Seeing a design running in the browser in minutes means I make more design decisions in the real medium, and fewer in Figma guesses.

6. Check it on a real phone, then do the boring states

Figma frames are always the perfect size. Real phones aren't. I check every page on an actual phone, then go through the states nobody draws: empty lists, very long names, slow internet, no internet, errors. This is where an app starts to feel trustworthy.

7. Motion last, and optional

Animation comes at the very end, once everything works without it. On this site, headlines rise in word by word and the page scrolls smoothly. Both switch off for anyone who has asked their device for reduced motion, and the text is fully there without JavaScript.

8. Ship small, ship often

Code goes to GitHub, and Vercel deploys every push. Work on a branch gets its own preview link I can open on my phone, or send to someone for feedback, before it goes live. Shipping is so cheap that there's no reason to batch up changes.

The tools I use as an indie app builder

• Figma for design, with variables for colours and type.
• Next.js for the app itself: pages, routing, images and fonts handled well by default.
• Tailwind CSS for styling, with the design tokens as its theme.
• Supabase when an app needs accounts and a database, like my bill splitting app.
• Vercel for hosting and preview links.
• Claude Code as a pair programmer.
• GitHub, to keep every version, and to share open-source work like my flashcards app.
• A domain name, usually around $12 a year.

Vercel, Supabase and GitHub all have free plans that comfortably fit a first version. So for many side projects, the domain is the only bill, and the real cost is your time.

That's a small, boring stack on purpose. Every tool is well documented and widely used, so I spend my time on the design, not on the tools.

Why I work this way

Building what I design means I can put a real thing in someone's hands, watch what they actually do, and fix it the same week. If you're deciding whether that's the right fit for your project, I wrote about it in designer or developer: who to hire first.