Guide6 min read

Share a Bolt Project With a Client

Show the build to a client who was never going to open the link.

Hand a working Bolt build to a client who will not open a preview link, with a video that stands in for the click they will not make.

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

A client rarely opens a preview link the way a developer does. Handed a URL to a Bolt sandbox session, a non technical client might click it, wait for it to load, get confused about which part is the actual product and which part is builder tooling, and give up before reaching the part that was supposed to convince them. The problem is not that the client is uninterested. It is that a raw link asks them to do work they were never signed up to do: navigating an unfamiliar interface to find a result someone else already knows how to reach directly.

A short video removes that step. Instead of asking the client to find the result themselves, it shows the result to them, in the order that makes sense, with narration that explains what they are looking at. This matters especially for a Bolt build, where the fastest path to a working preview is often a sandboxed in-browser session that a client has no reason to recognize as legitimate, and where a first time visitor may not be able to tell a loading sandbox from a broken link.

The gap between what a builder sees and what a client sees is easy to underestimate. A builder recognizes a sandbox loading screen as a normal part of the process, something to wait out for a second or two. A client with no exposure to that tooling has no such pattern to fall back on, and a delay that reads as routine to one person can read as a broken link to the other. A video sidesteps the difference entirely by presenting a finished result instead of asking the client to sit through the loading state themselves.

Why does a preview link fail with this audience?

A developer opening a Bolt preview link understands what they are looking at even if it takes a moment to load. A client does not have that context. They see an unfamiliar interface, possibly a loading delay, and no clear signal about where to look first. Some clients will not click the link at all if it arrived without explanation, since an unfamiliar URL from a builder can read as an easy thing to postpone.

What the client sees	What a video removes
An unfamiliar sandboxed interface	Replaced by a guided sequence with narration
A loading delay with no explanation	Replaced by a finished, edited result
No clear starting point	Replaced by a deliberate opening frame

What should the video actually show?

Match the video to what the client was told to expect, not to everything that was built. If the agreement was to deliver a working checkout flow, the video should show that flow completing, not a tour of the admin panel or a list of technical improvements the client did not ask about. A client watching a video that wanders past the agreed scope may start wondering whether the actual deliverable got lost somewhere in the tour.

Deploy the build to a stable URL the client can revisit later if they choose to.
Match the video to the specific outcome the client was told to expect.
Send the video first, with the deployed link included as an optional follow up.

How does deploying first change the handoff?

Deploying the build before sending anything gives the client a real, revisit-able address, even if they never click it. That matters because trust in a handoff often depends on knowing a fallback exists, not on actually using it. A client who knows they can return to a working link later is more likely to accept a video as sufficient for now, compared to a client who suspects the demo they were shown might not exist anywhere they can check again.

There is also a practical reason to deploy before recording rather than after. A sandboxed session used only for building can behave slightly differently once the same code runs on a real hosting target, and a video recorded against the sandbox can end up showing something the deployed version does not quite match. Recording against the address the client will actually be able to revisit keeps the video and the underlying build in agreement.

GogoScreen takes the deployed URL and a one line hint naming the agreed outcome, then returns a narrated MP4 with captions, cursor smoothing, click zooms, and dead air removed. If the flow needs a login, a demo account can be supplied for that single render, with the credential encrypted, used once, 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. Roughly one render in five fails or needs a retry, which is worth planning around before a deadline rather than discovering at the last minute.

How is this different from a portfolio or launch video?

A client handoff has an audience of one or a small handful of people who already have context about what was agreed, unlike the Bolt portfolio demo guide, which is written for a stranger with no prior context, or a launch gallery asset, which is written for a crowd of strangers scrolling quickly. A public facing landing page video is closer in spirit but still public facing, while a client handoff is usually private and specific to one relationship. The Bolt app review walkthrough guide is the closest relative, since both are about proving a specific outcome to someone who asked for it.

The same handoff need exists for other builders. The v0 landing page video guide, the v0 product hunt launch video guide, and the v0 share with a client guide cover the equivalent moments for a v0 build, where the output can lean more toward interface than wired up backend behavior, which changes what a handoff video can honestly claim about the flow underneath it. For the tradeoff between an interactive walkthrough and a fixed video, see the interactive demo versus demo video guide.

What should happen after the client sees the video?

The handoff usually is not the end of the relationship, so plan for what comes after the client responds.

If the client approves, keep the video as evidence of what was delivered and when.
If the client asks for a change, note it clearly rather than editing the same video.
If the project heads toward a public launch, the product demo video before launch guide covers what changes at that stage.

Treating the sent video as a record rather than a disposable message makes later disagreements easier to resolve. A client who cannot remember exactly what was shown weeks earlier benefits from being able to point back to a specific file with a specific date, and a builder benefits from the same record if the scope of what was agreed ever comes into question.

Keeping a clean record matters more than it seems in the moment. A demo video poster frame that clearly represents the delivered state helps when the video is filed away and referenced months later, and an agent handoff demo video is the right format if the next step is handing the build to another builder rather than to the client directly. If the relationship continues past this one delivery, a changelog video can carry future updates without repeating this full handoff process each time. For a comparison of tools that support this kind of client facing capture, see GogoScreen versus ngram. Review pricing, browse the rest of the guides and comparisons, or start from the GogoScreen homepage to try the workflow on your own deployed build.

Clarifications

Before you start

Why not just send the Bolt preview link?

A preview link works for a technical reviewer willing to click through and wait for a sandboxed session to load. Many clients will not do either, so a video that shows the same result removes that barrier entirely.

Does the client need to see the code?

No. A client is usually judging whether the result matches what was agreed, not reviewing implementation. The video should show the working app, not the editor.

What if the client asks a question the video does not answer?

Keep the deployed link available as a follow up. The video should answer the main question fast, with the link as a backup for anyone who wants to explore further.

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