Guide6 min read

Share a Windsurf Project with a Client

Some clients will never click the link. Send them the result instead.

Hand a working Windsurf build to a non technical client who will not open a preview link, using one video instead of a URL.

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

gogoscreen.com

Translate the request into the client's own words

Translate the request into the client's own words before deciding what to show.

Show the outcome before any interface detail

Show the outcome before any interface detail, since that is what they asked for.

Narrate in plain language, not product terminology

Narrate in plain language, not product terminology, so nothing needs explaining afterward.

Some clients open every link you send them. Others do not, whether from limited time, limited comfort with unfamiliar software, or simply a preference for being told rather than shown where to click. A Windsurf project built for that second kind of client needs a different handoff than a preview URL and a hopeful message. A short video that plays on its own, with no login and no navigation required, respects both the client's time and the reality that they may never have opened a staging link in their life.

Windsurf itself is a code editor, and the client almost certainly has never heard of it and does not need to. What they asked for was an outcome, described in their own words during a call or an email, not a technical feature. The video should answer that original request directly, using the client's own vocabulary rather than the interface's internal terms, since a client who has to translate unfamiliar labels back into their own request is doing work the video should have done for them.

This is a different problem from showing the same project to a technical audience. A Windsurf portfolio demo is judged by someone who wants to see craft and is willing to sit through some nuance. A client review video is judged by someone who wants a yes or no answer and will not sit through anything extra. Confusing the two, by sending a client something built for a portfolio audience, is a common way a client handoff goes wrong even when the underlying video is well made.

What does a non technical client actually need to see?

Start from the original request, not from the app's structure. If the client asked for "a way for customers to book a time," the video should show exactly that booking flow, described as booking, not as whatever the codebase happens to call the underlying object. Skip any screen the client did not ask about, even a polished one, since an unexpected screen invites a question about scope rather than confidence in the delivery.

Clients also read pacing differently than a technical reviewer does. A developer watching a review video can follow a fast cut between screens because they already understand the underlying structure. A client cannot, and a video that moves at developer speed will leave them unsure what they just watched. Slow the pacing down, let each screen sit long enough to register, and resist the urge to compress the video simply because a faster cut would look more polished to your own eye.

What the client asked for	What the video should show	What confuses more than it helps
A plain description of an outcome	That exact outcome, start to finish	Screens or terms they never mentioned
A fix to something broken	The same steps that used to fail, now working	A different area that was also touched
A new capability	That capability used the way they described it	Configuration options aimed at a technical user

A SaaS demo video checklist is a useful general reference for this kind of preparation, even though this specific guide is written for a client audience rather than a general buyer.

How do you prepare the build for a client who will not explore it?

Open the deployed route yourself and complete the exact task in the client's words. Confirm there is no leftover debug data, no placeholder text, and nothing on screen that would raise a question you would rather not field over email. A client who is not going to explore the app also is not going to give you the benefit of the doubt about anything that looks unfinished, since they have no other context for the project to weigh it against.

Walk the exact task the client described, in the order they described it.
Remove any debug or placeholder data that was left in during development.
Prepare a demo account if the flow needs a login, rather than sending real credentials.
Confirm nothing on screen would need a follow up explanation.

If a login is required, a demo account can be prepared for the render, and the credentials used 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 matters here specifically, since a non technical client is unlikely to know what to do with a login even if you sent one, and is better served by never needing one at all.

Think through what the client will do immediately after watching. If the natural next step is a reply saying yes, approve it, that reply should require nothing beyond the video itself. If the client would need to click through to verify something the video did not show, the video has not actually finished the job, and it is worth adding the missing piece before sending rather than waiting for a follow up question that a slightly longer recording could have avoided.

How should the hint and narration be written?

Translate the request into the client's own words before deciding what to show.
Show the outcome before any interface detail, since that is what they asked for.
Narrate in plain language, not product terminology, so nothing needs explaining afterward.

Write the hint the way you would explain the result over the phone, not the way you would describe it to another developer. If the client's original message used a specific phrase, reuse that phrase rather than substituting a more precise but unfamiliar term. Precision that requires a glossary is not precision the client can use.

What comes before and after this handoff?

If the client asked for a review before the work is considered done, this guide covers the delivery step, while the Windsurf app review walkthrough covers how to structure the flow around the original request itself. Once a project is client approved and heading toward a wider audience, a Base44 demo video style treatment, a Base44 landing page video, or a Base44 Product Hunt launch video each answer a different later question, even though the client handoff itself does not need any of that yet.

If pricing rather than delivery is the open question with this client, a demo video for a SaaS pricing page is a separate and later concern. If the client is watching from a public thread rather than a private message, that is closer to a Show HN demo video or an AI agent Product Hunt demo than to a private client handoff, and the tone should shift accordingly. The underlying mechanics stay the same either way, and the software demo video from a URL guide covers those mechanics in more depth if any step above was unfamiliar.

What should you check before sending it?

Watch the finished video as if you were the client, with no prior knowledge of the project. Confirm the outcome is visible without narration in case they watch muted on a phone, and confirm nothing on screen needs a follow up question to understand. Compare the format against Demosmith if you are weighing a different way to package this same handoff.

Leave room for a retry, since roughly one render in five needs one, and a client handoff is a bad place for a surprise delay. Every new account gets 60 seconds of video once, watermarked, which is often enough for a single client task, and after that, top up time never expires and time is used only when a render succeeds. Check pricing for the plans, browse more guides and comparisons, or start from the GogoScreen homepage with the route and hint this handoff is built from.

Clarifications

Before you start

Why not just send the client a preview link?

A preview link assumes the client will open it, understand what they are looking at, and interpret an unfamiliar interface correctly. Many non technical clients will not do any of that reliably, and a video removes the assumption entirely.

What should the video show a client who did not ask for technical detail?

Show the outcome they care about, described in their own language rather than the app's internal terminology, with enough context that they do not need to have seen the project before.

Is this different from a general demo video?

The recording workflow is the same. The difference is the audience. A client review video is written for someone deciding whether the work matches what they asked for, not for a stranger deciding whether to try the product.

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