Guide6 min read

Cursor Share With a Client

Show a client the build working, without asking them to open a link.

Hand a non technical client proof that a Cursor build works, starting from a real deployment instead of a link they will not open.

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

gogoscreen.com

Confirm the deployment the client will see

Confirm the deployment is live and stable before recording anything the client will be shown.

Pick the flow the client actually asked for

Pick the one flow that matches exactly what the client asked for, not a broader tour of the build.

Write the hint and send the file

Write a hint naming the start, the action and the result, then send the finished file instead of a link.

A client who commissioned work from a Cursor project has no interest in the editor, the language, or how the code is organized. They want to know whether the thing they paid for is done. Sending them a link asks them to trust an address they have never seen, navigate an interface they do not know, and find the relevant part themselves. A short video removes every one of those steps. They press play and watch the requested work happen.

GogoScreen takes a web app URL and a one line hint about what to show, then returns a narrated, edited MP4 with zooms on clicks, cursor smoothing, dead air cuts and burned in captions. For a Cursor build specifically, there is a step before any of that: the app has to be deployed somewhere reachable first, since Cursor itself does not generate a preview link. Once that deployment exists, the tool works the same way it would against any other URL.

Why does a Cursor handoff need an extra step?

Confirm the deployment is live and stable before recording anything the client will be shown. A platform that ships with an automatic preview link makes this step invisible. A Cursor project does not, so it has to be handled deliberately, usually by deploying to whichever host the team already uses for the project, or setting up a deployment specifically to support the handoff. Do this before writing the hint, not alongside it, because the deployment can take longer than expected if it has not been done before.

Check that the deployment is one that will still be live when the client actually watches the video, not a temporary environment that gets torn down the next day. A client who reaches out with a follow up question a week later and finds the link dead will read that as evidence the work was never really finished, even if the recorded flow was accurate at the time.

This handoff is different from the Cursor portfolio demo guide, which is written for a general audience deciding whether the developer is worth hiring, and from the Cursor app review walkthrough guide, which is written for a reviewer checking a build against a written brief. A client handoff sits between those two: the audience already commissioned the work, so the only open question is whether the specific thing they asked for now exists and works.

What the client is judging	What a raw preview link asks of them	What the video removes
Is the requested work done	Click through, navigate, find the relevant screen	They watch the exact flow completed
Does this look trustworthy	Evaluate an address they have never seen	Nothing to click, nothing to question
Does this match what was asked	Compare the app against their memory of the brief	The narration can name the request directly

How do you choose the flow to show?

Pick the one flow that matches exactly what the client asked for, not a broader tour of the build. Go back to the original request rather than the current state of the code. If the brief asked for an order form that sends a confirmation email, show precisely that, completed, rather than a wider look at the admin panel behind it. A client comparing the video against their memory of the request will notice if the two do not line up.

Confirm the exact route the requested flow starts from.
Use plausible sample data rather than empty tables or placeholder text.
Remove any other client's information from the environment before recording.
If a login gates the flow, arrange a demo account rather than a real one.

Because Cursor builds tend to include genuine backend logic rather than a quick mockup, this preparation step matters more than it would for a lightweight prototype. Test the flow by hand immediately before recording so the state captured in the video matches what was last verified working.

Resist the temptation to show more than the client asked for, even when other parts of the build happen to be finished and impressive. A client watching a clip that drifts past the scoped request into unrelated territory may wonder whether the original ask got lost somewhere in the process. If there is additional finished work worth mentioning, raise it separately, after the client has confirmed the requested flow is exactly what they wanted.

If a login gates the flow, a demo account can be supplied through the approved process, and the credentials 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. Do not use the client's own account or credentials for this, even if it would be the fastest way to show the exact data they expect. A dedicated demo account keeps the recording process separate from any account that matters to anyone, and it means the client never has to wonder what happened to their own login afterward.

Write a hint naming the start, the action and the result, then send the finished file instead of a link. State it in the client's own words wherever possible, matching how the original brief described the request rather than how the codebase happens to label things internally.

Confirm the deployment is live and stable before recording anything the client will be shown.
Pick the one flow that matches exactly what the client asked for, not a broader tour of the build.
Write a hint naming the start, the action and the result, then send the finished file instead of a link.

What should you check before sending it?

Roughly one render in five fails or needs a retry, so watch the candidate before it reaches the client. The readme product demo video guide is a useful comparison here, since both audiences need the video to stand on its own without requiring a separate explanation alongside it. If the app includes a voiceover heavy narration style, the voiceover for a product demo video guide covers making sure the narration matches the flow precisely rather than reading like generic marketing copy.

If the client's product is still pre launch, the demo video for a SaaS waitlist guide covers a related use case for building anticipation before the app is fully public. If the build in question was made in v0 instead of Cursor, the v0 app demo video guide covers the same handoff discipline for a project with a different starting point. For a broader launch context beyond one client, the AI agent launch checklist covers the wider set of steps a launch usually needs.

For the same job across other Cursor pages, see the Windsurf demo video guide, the Windsurf landing page video guide and the Windsurf Product Hunt launch video guide, which cover the equivalent handoff for a different AI assisted editor. For a direct comparison of recording tools, review GogoScreen versus Demosmith. Start from the homepage for the URL and hint workflow, browse guides for the rest of the series, check comparisons against other tools, and review pricing before submitting a render for a client.

Clarifications

Before you start

Why is a video better than a link for a Cursor client handoff?

A client who does not build software often will not click an unfamiliar link, and a Cursor project has no automatic preview URL to point them at anyway. A video removes both problems by showing the work directly.

Does the client need to know how the app was built?

No. The client is judging whether the requested work is done, not which editor or tooling produced it. Keep the narration about the flow, not the build process.

What if the app requires a real login?

Use a disposable demo account rather than the client's own credentials or a personal account. Supplied credentials 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.

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