Guide6 min read

Cursor Portfolio Demo Video

Show a reviewer the app working, not a screenshot of it.

Turn a Cursor built project into a portfolio entry that shows the flow running, using a reachable route and one clear user job.

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

A portfolio entry built with Cursor has one job: convince someone scanning a list of projects that this one is worth a closer look. That person is usually a hiring manager, a technical lead running a take home review, or a prospective client comparing a few freelancers. None of them will clone the repository before deciding whether to keep reading. They will look at whatever sits next to the project title, and a static screenshot of a form or a dashboard tells them almost nothing about whether the thing actually works.

Cursor itself is a code editor, not a hosting platform. It does not publish a project to a public URL or keep a preview running on its own. Whatever the developer builds runs locally during the work, on a dev server reachable at a local address, and gets deployed afterward to whichever host the developer picked, if they deployed it at all. That gap between "the code exists" and "the app is reachable" is exactly where a portfolio entry can fail even when the underlying work is solid. A video sidesteps the gap. It captures the app in its current reachable state, whether that state is a deployed URL or a local dev server, and turns it into something a reviewer can watch without running anything themselves.

What job should the portfolio video show?

Choose the single interaction that best demonstrates the skill you want credited. A project management tool should show a task moving from one column to another and staying there. A data tool should show a file going in and a transformed result coming out. Resist the pull to open every screen the project has. A reviewer who sees six unrelated features in ninety seconds usually remembers none of them, while a reviewer who sees one convincing interaction remembers that the builder can ship a working feature end to end.

Portfolio job	What it proves	What to cut
One core interaction	The build actually functions, not just renders	A tour of settings, admin panels, and unrelated pages
A visible before and after state	Cause and effect inside the app	Narration that describes code instead of the screen
A believable data state	The app was tested with real inputs, not a blank demo	Placeholder text left over from scaffolding

If the project is a smaller companion piece rather than the headline project, a changelog video for a SaaS style clip works better than a full walkthrough, since it can focus on one shipped change rather than the whole product.

How do you prepare a Cursor project for recording?

Open the reachable route by hand first, the same way you would test any web app before it goes in front of someone else. Confirm there is no broken redirect, no half finished onboarding step, and no empty state sitting where the meaningful result should be. Cursor projects often start life with placeholder data from a starter template, and that data reads as unfinished the moment someone else sees it. Replace it with something that looks like a plausible real use of the tool before you record anything.

Confirm the route opens without an error or a stuck loading state.
Replace starter template placeholder content with data that matches the app's actual purpose.
Decide whether the flow needs a login, and prepare a disposable account if it does.
Note the exact starting point and ending point of the interaction you want shown.

If the project sits behind authentication, a demo account can be supplied through the normal GogoScreen process, and any credentials given are encrypted, used for a single render, then deleted. When a storyboard is planned first, the credentials are kept encrypted for that session and deleted at most two hours after their last use. That is a meaningful detail for a portfolio builder, since a side project login is still a login you would rather not hand out casually. For a companion guide on setting that account up correctly, see preparing a demo account for a product video.

Give some thought to whose data appears on screen. A side project built in Cursor sometimes carries real information from early testing, a personal email address used to sign up, or a friend's name typed in while trying the feature out. None of that belongs in a public portfolio entry. Swap it for data that is obviously representative rather than obviously real, and check every visible field, not just the one the interaction is centered on.

What does the flow hint need to say?

Pick one job the app performs that a stranger can understand in ten seconds.
Reach the state that proves the job actually completed, not just the empty starting screen.
Record the flow instead of a screenshot, so a reviewer sees the app respond.

Write the hint the way you would explain the app to someone standing next to you, using the same words the interface uses. If the app calls something a workspace, the hint should say workspace, not folder. A vague hint such as "show the dashboard" invites a recording that wanders across the interface without ever reaching a result, and a portfolio piece that wanders is worse than no video at all.

Where should the finished video live?

Put the video at the top of the project's portfolio entry, before the description and before the tech stack list. A reviewer who has to scroll past three paragraphs to find proof the app works has usually already moved on. If the same project also needs a public facing page of its own, the placement question changes, and a landing page demo video treatment or a product hunt launch video treatment answers a different brief than a portfolio entry does, even when the underlying footage is similar. A general Windsurf demo video covers the same underlying recording workflow if the project happened to be built on that platform instead, and the preparation steps carry over either way.

If the portfolio itself needs to reach a specific non technical reviewer, such as a recruiter forwarding your work to a hiring manager who will not click through, a Windsurf share with a client style handoff explains how to package the same kind of proof for someone who wants a direct answer rather than a page to explore.

A portfolio video is also a good candidate for reuse. The same clip, trimmed differently, can support a staging app demo video shared privately with a mentor for feedback, or a shorter cut aimed at someone deciding whether a new SaaS deserves its first demo video. Keep the original recording focused on one job so those trims stay easy to make instead of requiring a full re-record. If a follow up review is planned once the code changes, the Cursor app review walkthrough covers how to hand a reviewer the flow that proves a specific request was completed, which is a related but separate use of the same underlying workflow.

What should you check before publishing it?

Watch the finished video once as if you have never seen the project before. Check whether the opening frame makes sense without sound, since many reviewers will watch muted. Confirm nothing in frame reveals a real email address, a real name, or any data you would not want public. A product demo gif alternative is sometimes the right format instead of a full video, particularly when the portfolio entry sits in a grid of small cards rather than a full page, so decide the format before you commit to a length.

Remember that roughly one render in five needs a retry, so leave time in your schedule rather than recording the night before an interview. Every new account gets 60 seconds of video once, watermarked, which is often enough for a single portfolio interaction. After that, videos use time from a plan or a top up; top up time never expires, and time is used only when a render actually succeeds. None of that changes the editorial bar: the video only earns its place in the portfolio if a stranger can watch it and believe the app works. Compare the finished result against Demosmith if you are choosing between capture tools, check pricing for plans and top ups, browse the rest of the guides and comparisons library for adjacent formats, or start again from the GogoScreen homepage if the project needs a different kind of asset entirely.

Clarifications

Before you start

Why does a Cursor portfolio entry need a video instead of a screenshot?

A screenshot shows one static moment. A hiring manager or client cannot tell from it whether the interaction actually works. A short video of the real flow answers that question in seconds, which is what a portfolio entry is for.

Does Cursor host the app for the portfolio video?

No. Cursor is a code editor, not a hosting service. The developer runs the project locally during work and deploys it separately to whichever host they chose. The video should show whichever of those is reachable at the time of recording.

What if the Cursor project only runs on localhost?

A localhost flow can still be recorded and reviewed like any other reachable route, as long as it opens in a browser. Treat the deployment question as separate from the portfolio question and record the state that exists today.

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