Bolt to Figma: Turn a Bolt.new App Into Editable Layers

The Bolt to Figma workflow

Open the Bolt project and make sure the screen you want is working in Preview. Navigate to the exact route, modal, form step, empty state, or populated dashboard state the team needs to discuss. If the embedded preview feels cramped, open the rendered app in its own Chrome tab before capturing.

Run CopyFig on the visible page, choose the full page or one element, and paste the result into Figma. Keep the original capture untouched, then duplicate it before changing copy, spacing, colors, hierarchy, or components.

• Let fonts, images, charts, and client-side data finish rendering.
• Capture one focused state at a time and name the Figma frame clearly.
• Repeat at real browser widths for responsive layouts.
• Keep a captured baseline beside the refined design direction.

Use Preview for iteration and the published site for review

Bolt shows the latest app in Preview while you build. That makes Preview the fastest source when you are still prompting, comparing variants, or fixing one screen at a time. Capture only after Bolt has finished the current change so the frame represents a coherent state.

A published Bolt site is better when the team needs a stable reference. Bolt can publish to a bolt.host address, and published changes are controlled separately from the project preview. Open that site in a normal Chrome tab, verify the route and data state, then capture it as the review baseline.

Capture flows as separate Figma frames

One hero screen rarely explains an app. Capture the important journey as a sequence: entry screen, populated state, form, validation error, success state, settings, and any responsive variant that changes the interaction.

Arrange those captures left to right in Figma and label them by action rather than by vague screen numbers. The result becomes useful for critique and stakeholder review because the team can see the whole path instead of clicking through one browser state at a time.

• Start or landing state.
• Primary action and form state.
• Loading, empty, validation, and error states.
• Success state and the next meaningful action.

Why editable layers beat Bolt screenshots

A screenshot is fine when the job is simply to remember what the app looked like. It is limiting when the team needs to rewrite a label, compare two card structures, move a call to action, inspect a section, or explore a different hierarchy.

CopyFig turns the rendered page into more useful Figma material: editable text, frames, fills, images, and layout pieces where supported. Some cleanup is still expected, but the team starts from the real interface instead of tracing pixels manually.

Clean up the AI-built UI deliberately

Bolt is excellent at getting to a working first draft. That does not mean every visual decision should become part of the product system. Use Figma to separate quick generation choices from intentional design decisions.

Normalize the type scale, spacing rhythm, color roles, component states, and content hierarchy. Replace one-off cards and buttons with the team’s real components. If several pages use slightly different versions of the same pattern, put the captures side by side before deciding which structure to keep.

• Consolidate repeated buttons, inputs, cards, and navigation items.
• Resolve inconsistent spacing and typography before polishing details.
• Check contrast, focus, errors, labels, and keyboard-visible states.
• Document which changes should return to Bolt or the production code.

Protect private data before sharing

A browser capture can include anything visible in the app: names, email addresses, customer records, test credentials, internal URLs, and other project data. Move to a safe demo account or replace sensitive values before capturing whenever possible.

After pasting into Figma, inspect the complete frame before sharing it outside the immediate team. Remove private content and keep access restrictions appropriate for the source application.