Guide6 min read

Figma Make Portfolio Demo

Put the running build in your portfolio, not a screenshot of it.

Show a Figma Make build running in a portfolio instead of a static screenshot, and prove the flow works before a hiring manager asks.

See how it worksYour first 60 seconds of video are free, with a watermark.
Verify your email to download it.

A portfolio entry built around a screenshot is asking a reviewer to trust that everything below the fold also works. A screenshot proves layout. It does not prove that a button does anything, that a form validates, or that the interaction a hiring manager actually cares about behaves the way the still image implies. The gap between "looks finished" and "works" is exactly what a video closes, and it is the single biggest difference between a portfolio entry that gets a second look and one that gets scrolled past. A reviewer moving through a stack of applications rarely has time to open every linked project, so the entries that survive that first pass are the ones that answer the working question without requiring a click through.

A Figma Make build is well suited to this because the output is a working prototype at a shareable preview link, not a design file that needs Figma itself open to inspect. That link is usually reachable without a login, since most Figma Make projects are prototypes rather than software with a full account system behind them, which means the flow shown in the video is the same flow a reviewer could open and try for themselves right after watching.

What should a portfolio demo prove?

A portfolio demo should prove the one interaction that took the most judgment to get right. That is rarely the login screen or the navigation bar. It is usually a specific piece of logic: a form that reacts intelligently to input, a layout that reflows in a way that took real iteration, or a flow that solves a genuinely awkward interface problem. Name that moment before recording anything, the same way you would name the single strongest point in a written case study.

A launch gallery video has to win a stranger's attention in the first two seconds. A portfolio viewer has already chosen to look closer, usually because a resume or a link brought them there, so the video can afford a slightly longer arc: a beginning that sets up the problem, a middle that shows the interaction, and an end that shows the resolved state.

Portfolio moment	What it should prove	What to leave out
Setup	The problem the interaction solves	A tour of unrelated pages
Interaction	The specific logic or layout choice	Every alternate path through the same screen
Resolution	The state that shows the interaction worked	A narration heavy sales pitch

How do you prepare the build for recording?

Open the preview link the way a reviewer would, cold, with no assumptions about what state it should be in. Check for anything that reads as unfinished: placeholder text left from an earlier draft, an empty list with nothing in it, or a component still showing default values instead of the content you meant to demonstrate. A reviewer evaluating a portfolio entry is already looking for reasons to move on to the next one, and an obviously unfinished detail hands them that reason for free.

Open the preview link cold and confirm nothing looks like an earlier draft state.
Fill any list, form, or table with content that reads as intentional, not empty.
Test the specific interaction end to end before writing the hint for the render.
Remove anything that resembles a real person's data, even placeholder text that looks too specific.

Fill in data that supports the interaction without pretending to be a real user's information. A calendar with no events or a dashboard with no numbers gives a reviewer nothing to react to, while data that is obviously a stand in still lets the interaction read clearly.

Putting the process in order helps keep the video scoped correctly from the start:

Name the strongest interaction in the build before recording anything.
Prepare the preview link so it opens cold with no unfinished state visible.
Write the hint naming the starting state, the interaction, and the result, then review the render before publishing it.

How specific should the hint be?

Write the hint the same way you would describe the piece to a design reviewer in an interview. Name the starting state, the interaction, and the result. "From the empty form, enter a value that triggers the validation message, then show the corrected state" is concrete enough that GogoScreen's render has a clear target and a concrete enough scope that a reviewer of the finished video can check the render against the hint.

GogoScreen returns a narrated, edited MP4 built from that hint and the URL, with zooms on the click that matters, cursor smoothing, dead air cuts, and burned in captions. None of that substitutes for choosing the right interaction. A cleanly edited recording of a generic screen is still a generic portfolio entry, and reviewers who look at many of these in a day notice the difference between a specific claim and a general one quickly.

What goes around the video in the portfolio?

Pair the video with a short written note naming the problem, the decision, and why that decision was the right one. The video shows the result. The text explains the thinking, which is often what a hiring manager or client is actually screening for. Keep the two separated rather than layering process narration over the running interaction, since a reviewer trying to watch the interface work and read an explanation at the same time tends to absorb neither well.

Review the finished render against the interaction as it actually behaves before publishing it anywhere. Roughly one render in five needs a retry or fails outright, and time is used only on a successful one, so build a short review pass into the process rather than publishing the first file that arrives. That review pass is also the point at which a mismatch between the hint and the interface tends to surface, so it is worth watching the whole clip once before deciding it is ready to go live.

Where does this fit with adjacent guides?

For a reviewer who needs to sign off before the build ships rather than judge it as a portfolio piece, the Figma Make app review walkthrough covers that separate audience and the handoff problem that comes before a portfolio entry is even worth making. For a similar treatment on another builder, compare a Bubble demo video, a Bubble landing page video, a Bubble Product Hunt launch video, and sharing a Bubble project with a client, since Bubble apps more often sit behind a real login by default.

For proving a specific interaction result rather than a general flow, the AI agent test result demo video guide and the AI agent QA demo video guide cover adjacent proof formats. An embedded product demo video is useful once the portfolio entry needs to sit inside a page rather than link out, a Lovable app demo video covers the equivalent job for that builder, and a broader product walkthrough for a SaaS is the right format once the entry needs to cover more than one interaction. For a comparison of recording tools for this kind of work, read GogoScreen versus Clueso. Start at the GogoScreen homepage, check pricing, browse the full guides library, or see the rest of the comparisons.

Clarifications

Before you start

Why is a screenshot not enough for a portfolio entry?

A screenshot only proves the interface can be laid out correctly at one frozen moment. It cannot show whether the interaction actually works, which is usually the exact thing a reviewer is trying to judge.

Should the portfolio video show the Figma Make process or the finished app?

Show the finished app doing the job it was built for. The process belongs in a case study write up next to the video, not inside the same clip, since mixing the two dilutes both.

Do I need real data in the demo to make it convincing?

You need plausible data, not real data. Placeholder content that reads as intentional is enough to show the interaction working, and using real customer material is not appropriate for a public portfolio entry.

Paste a URL, describe one flow, and get a demo video of your web app.

Your first 60 seconds of video are free, with a watermark. Verify your email to download the video.

View pricing Read the guides