Guide6 min read

Share a Base44 Project With a Client

Show a client the build instead of sending a link they will not click.

Hand a Base44 build to a non technical client with a short video instead of a preview 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 what the client is waiting to see

Confirm exactly what the client is waiting to see before recording anything, rather than assuming the whole build needs a tour.

Prepare a route without real client data

Prepare the route with safe example data so no real client information appears in a file that could be forwarded.

Review against the original request

Review the finished candidate against the client's original request before sending it, not just against whether the app looks finished.

A client who commissioned a Base44 build rarely wants to log into a preview environment and hunt for what changed. They want to see the specific thing they asked for, working, in a form they can watch on a phone between meetings. A video does that job better than a link, and it does it without requiring the client to remember a demo password or navigate an interface they have never seen before. Many clients who commission this kind of build are not technical, and a preview URL that opens on an unfamiliar dashboard can feel like homework rather than a status update, which is exactly the impression a builder wants to avoid right before asking for approval.

GogoScreen turns a web app URL and a one line hint about what to show into a narrated, edited MP4, with click zooms, cursor smoothing, dead air removed, and captions burned in for anyone watching without sound. It can use a demo account when the build sits behind a login, which most Base44 projects do by default. None of this is a promise that every render will land on the first try. Build a few minutes of review time into the handoff, especially before a client facing send.

What is the client actually waiting to see?

Before recording, reread the last message from the client and identify the specific ask. If they requested a new field on a form, the video needs to show that field, not the whole form redesigned around it. If they asked whether the export feature works, the video needs to show an export happening and the resulting file appearing, not a general tour of the reporting section. Scope creep in a client update video usually comes from wanting to show off more than what was asked, and it tends to bury the one thing the client is actually checking for.

What the client asked for	What the video should isolate	What tends to dilute it
A specific fix or feature	That exact action and its visible result	A tour of unrelated screens built earlier
A general status check	The most recently completed piece of work	Re-showing features already approved before
A go or no go decision	The state the decision depends on	Framing that argues for one answer over another

A general Base44 demo video is useful if the client update needs to sit alongside a broader demo of the app, but the two should stay separate rather than combined into one longer video that tries to do both jobs.

Most Base44 builds include account handling from generation, so the recorded flow will likely start at or just after a sign in screen. Use a demo account created for this purpose rather than the client's own login, even if the client's login would technically work. Any credentials supplied for the render are encrypted, used for a single render, then deleted, which is the precise and accurate way to describe that handling. When a storyboard is planned first, the credentials are kept encrypted for that session and deleted at most two hours after their last use.

Populate the demo account with example data that resembles what the client would expect to see, without using the client's actual customer names, real documents, or production records. A video is easy to forward, screenshot, or post somewhere it was not meant to go, and client data in a demo asset is a risk that is simple to avoid by preparing the route properly first.

How should the video be framed for someone non technical?

Write the one line hint in plain terms the client would recognize from their own request, not in the internal terminology the build might use. If the client called it "the dashboard" in their message, do not switch to calling it "the analytics module" in the hint just because that is the label inside the app. Consistency between what the client said and what the video shows makes the update easier to trust at a glance.

Reread the client's most recent request before choosing what to show.
Use a demo account with example data, never the client's real information.
Match the language in the hint to the language the client used.
Keep the video to the one thing that was asked for, not a broader tour.

What if the client update reveals unfinished work?

A recorded flow sometimes surfaces a problem that was not visible until the video forced a full run through, such as a step that works only with certain data or a result that appears inconsistently. Treat that discovery as useful information rather than a reason to reshoot the video until the rough edge disappears from frame. A client who is going to notice the issue eventually is usually better served by an honest note attached to the video than by a version that was staged to avoid the problem.

Decide before sending whether the issue is small enough to mention in a caption or large enough that the client update should wait until it is fixed. A missing field or an awkward transition is often fine to note in passing. A flow that fails outright on the exact action the client asked about usually means the update is not ready yet, and sending a video anyway just moves the difficult conversation later without making it easier.

Note any rough edge honestly rather than editing around it.
Decide whether the issue is minor enough for a caption or serious enough to delay the send.
Never let the video imply a state of completeness the build has not reached.

What is the short version of this process?

Confirm exactly what the client is waiting to see before recording anything, rather than assuming the whole build needs a tour.
Prepare the route with safe example data so no real client information appears in a file that could be forwarded.
Review the finished candidate against the client's original request before sending it, not just against whether the app looks finished.

What should you check before sending it to the client?

Watch the finished candidate against the client's original message one more time. Confirm the visible result actually resolves what they were asking about, and that nothing unfinished or unrelated slipped into the frame. If a retry is needed, that is a normal part of the process, roughly one render in five needs one, and time is used only when a render succeeds, so a failed attempt during preparation costs nothing beyond the wait. Every new account gets 60 seconds of video once, watermarked, with email verification required to download it, which is often enough for a single client update.

What comes next in the handoff?

Once the client accepts the update, the same build often needs other assets for other moments. A Product Hunt launch video has its own separate constraints if the project is heading toward a public launch. A portfolio entry can reuse the finished build once the client relationship allows it, and a formal review walkthrough is the right format if a client or stakeholder needs a structured confirmation that the build meets the original requirements rather than an informal update.

For the same handoff job on a different builder, see the guides on Figma Make demo videos, Figma Make landing page videos, and Figma Make Product Hunt launch videos, all relevant if the same client is evaluating builds across more than one platform. Related reading includes the AI agent Product Hunt demo guide, the non technical founder demo video guide, the product announcement demo video guide, the investor demo video guide, and the changelog video for a SaaS guide. Compare direct URL options at GogoScreen versus Demosmith, check pricing, or browse the rest of the guides and comparisons from the homepage.

Clarifications

Before you start

Why not just send the client the preview link?

Some clients will not open a raw preview link, especially one that requires signing in with a demo account first. A short video removes that barrier and shows the exact result the client is waiting to evaluate.

What should the video cover for a client update?

The specific thing the client asked for, shown as a finished action with a visible result. Avoid a broader tour that reintroduces features the client already approved in an earlier round.

Is it safe to use the client's own data in the video?

No. Use prepared, non sensitive data even when the client's actual data exists in the build. A video is easy to forward or post publicly by accident once it leaves your hands.

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