Short answer: export the code, split the monolithic component into files, replace hardcoded arrays with props or a data layer, add types, then open a pull request that references the Figma frame. Budget one to two days for a five-screen app.

What does the export actually contain?

Typically a single large component file, inline styles or utility classes, and hardcoded sample data repeated inside render logic. It runs, but every screen lives in one function and there are no abstractions.

Treat it as a visual reference with working behavior, not as a foundation. Your job is to preserve the interaction and re-implement the structure.

How do you clean up the export? Step by step

1. Run the export locally and confirm it renders at the same breakpoints as the Figma frame.
2. Split the root component into one file per screen and one file per reusable element.
3. Move hardcoded arrays to props with typed interfaces.
4. Replace inline color and spacing values with your design tokens or CSS variables.
5. Add the missing states — loading, empty, error — which Make almost never generates.

Step five is the one people skip. A prototype shows the happy path; production code needs the other three states, and skipping them means the first real bug report lands the week after launch.

What should the developer keep versus rewrite?

Layout is the most expensive thing to reconstruct by hand, so preserving it is where the time savings come from. Data and state management should always be rebuilt against your real API.

How do you keep design and code from drifting?

Reference the Figma frame URL in the pull request description and in a comment at the top of each converted component. When the design changes later, the reviewer can diff against the source frame in seconds.

If your team uses Figma variables mapped to design tokens, the conversion is much cleaner — generated values become token references rather than magic numbers. Teams without tokens spend most of the cleanup time on exactly this.

When should you not use Make output at all?

If the prototype is being folded into an existing design system, the generated component structure will fight your conventions. Rewriting from the frame is often faster than reconciling two sets of patterns.

Make output pays off best for new screens in a young codebase, or for internal tools where consistency demands are lower. In a mature monorepo with strict lint rules and a component library, treat the export as a spec and write the components properly.

Quick Summary

• Make exports a single large component with hardcoded data — treat it as a reference.
• Split into per-screen and per-element files, and lift data into typed props.
• Replace inline colors with design tokens and add loading, empty, and error states.
• Keep layout and interaction; rewrite data, state, and component boundaries.
• Link the Figma frame in the PR so future design changes are diffable.

Short answer: open a design in Figma, launch Make from the file, attach the frames you want, then describe the behavior in a prompt. You get an interactive build you can preview, edit, and export as React.

What is Figma Make?

Make is an AI feature inside Figma that generates functional prototypes. Where classic prototyping wires up static screens, Make writes actual components with state, form handling, and simple data flow.

It is available on paid Figma plans and has a limited number of generations per month depending on your seat. Output is React with Tailwind-style classes, which makes it reasonable to hand to a developer.

How do you start a Make project?

1. Open your design file and select the frames that represent the app.
2. Click Make, then attach the selected frames to the project.
3. Write a prompt describing what the app does, not just what it looks like.
4. Preview the result in the Make canvas and interact with it.
5. Iterate with follow-up prompts for behavior you want changed.

Attaching completed frames produces far better results than starting from a blank prompt. Make reads your spacing, type scale, and color tokens, so the generated app actually matches the design system.

How should you write the prompt?

Describe interaction, not appearance. The visuals already come from the frame.

Behavioral prompts are where Make earns its keep. “The list filters as I type” is a state change a static prototype cannot express.

What can it not do?

Three real limits. There is no backend: data lives in memory, so refreshing resets everything. There is no authentication. And the number of generations per month is capped by your plan, so long iteration cycles get expensive fast.

Generated code is also a starting point, not production quality. Expect hardcoded strings, minimal error handling, and component boundaries that need rework before it fits a real repository.

When is Figma Make the right tool?

It fits designers who want to test a flow with real interaction before writing a spec, and product teams who want a demo stakeholders can click through. The design-to-code fidelity is genuinely useful for reducing handoff arguments.

Skip it if you need a working product — a code-first tool with a real backend will get you there faster. Make is for validating ideas, not shipping them.

Quick Summary

• Figma Make generates functional React prototypes from your Figma frames.
• Attach completed frames first; Make inherits your spacing and type tokens.
• Prompt for behavior like filtering and validation, not for looks.
• No backend, no auth, and generation counts are capped by your plan.
• Great for design validation and demos, not for shipping production apps.