Guide6 min read

Share a Replit Project With a Client

Some clients will never open the deployed link. Show them the result instead.

A deployed Replit app is a link your client will not open. Here is how to send them ninety seconds of it running instead.

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

A client who commissioned a Replit build usually wants a straight answer to one question: does the thing they are paying for work yet. Sending them a bare deployed link asks them to find the right screen, understand what they are looking at, and form a judgment on their own, which most clients are neither equipped nor willing to do. A short video answers the actual question instead of handing over that task.

The detail that trips builders up here is the same one that matters for a launch video: a Replit project has a workspace where the app is built and a deployed route where it actually runs. A client should be judging the deployed version, since that is the version they would actually reach if they clicked the link themselves. A video recorded against the workspace can show something more polished, or simply different, than what is actually live, which creates a gap the client will eventually notice.

That gap tends to surface at the worst possible moment, usually when the client tries the link themselves after seeing a confident update and finds something that does not match. Recording against the deployed route every time removes the temptation to show the more polished but not yet live version, even when that version genuinely represents where the work is heading.

Why does a status update need its own video?

A written status message is easy to misread. "The dashboard works now" means something different to the person who built it than to the client reading it cold, and a raw deployed link gives a non technical viewer no help interpreting what they land on. A video removes both problems by showing the actual deployed screen doing the actual thing.

Update format	What it proves	What it leaves open
Written status message	That work happened, in general terms	Whether the specific feature works as described
Raw deployed link	Nothing on its own to a non technical viewer	Whether the client can find or interpret the right screen
Short video on the deployment	The specific flow, in the state it is actually in	Nothing, if scoped to the right question

This is a narrower job than a landing page video, which has to convince a cold stranger from a standing start. A client update only has to answer someone who already knows the project and is waiting on a specific piece of it.

That difference changes the right length for the video as well. A landing page video needs enough setup to earn attention from someone with no reason yet to care. A client update can skip straight to the result, because the client's reason to care was established the moment they asked the question this video is answering.

How do you choose what to show a client?

Start from the last question the client actually asked, not from whatever part of the build happens to be most finished. If they asked whether the checkout flow works, show the checkout flow completely, from start to result, on the deployed route. Padding the video with unrelated screens to make the update look bigger erodes trust faster than an honest, narrow update does.

Reread the last message or ticket where the client raised the question.
Confirm the answer is reachable on the live deployment, not just the workspace.
Prepare a safe example state rather than an empty or placeholder screen.
Leave out anything unrelated, even if it happens to be finished.

If the build genuinely is not finished, say so plainly next to the video rather than dressing up an incomplete state. The portfolio demo guide covers a different situation where the project is deliberately chosen because it is finished, which is a useful contrast for deciding how much polish this particular update actually needs.

A client update is judged on honesty more than on completeness, which is a different bar than a portfolio entry has to clear. A builder who shows a rough but working flow and says plainly what is left will usually keep more trust than one who waits for everything to be polished before sending anything at all. Waiting too long between updates creates its own kind of doubt, regardless of how good the eventual update turns out to be.

How do you prepare the deployment for a client audience?

Open the deployed route the video will use and confirm it reaches the relevant screen directly, with no stale build or unexpected interruption in the way. Use realistic example data rather than an empty state, since an empty screen gives a non technical viewer nothing to judge and can read as more unfinished than the underlying work actually is.

Identify the exact question the client asked or the milestone they are waiting on.
Confirm the answer is reachable on the live deployment, not only in the workspace.
Record a short video and send it with a sentence naming what it shows and what remains outstanding.

If the relevant flow sits behind a login, a disposable demo account through the approved process is appropriate, and writers should not handle the credential directly. The app review walkthrough guide covers a related situation where the audience is checking the build against a specification rather than simply checking on progress.

Time this check close to when the video will actually be recorded, not to when the flow was last confirmed working. A deployment can pick up an unrelated change between the two moments, and a client who receives a video of a flow that no longer matches the live build loses more trust than one who receives no update at all that week.

How should the video be sent?

Never send a video with no context and let the client guess what it proves. A single sentence above the link, naming what the video shows and what remains outstanding, does more for trust than the video itself. Clients remember whether updates were honest more than they remember whether every feature shipped on the original schedule.

Keep a light record of what was sent and when, tied to the deployment state at the time. A client who asks about progress weeks later benefits from a builder who can point to the exact update and the exact version of the deployment it was recorded against, rather than reconstructing the timeline from memory after the fact.

For a builder shipping the same kind of build on a different platform, the Bolt landing page video guide and Bolt Product Hunt launch video guide cover adjacent problems there, and the Bolt share with a client guide covers this exact situation on that stack. For a comparison with a manual screen recording workflow some teams already use for client updates, read the Loom alternative for a product demo guide. An investor update demo video and an AI agent release handoff video both cover related but distinct stakeholder update formats, and an embedded product demo video covers placing this kind of asset directly inside a tool the client already uses. An AI agent bug reproduction video is relevant when the update is about a fix rather than a new feature. For a comparison with a manual screen recording tool, read GogoScreen versus Clueso. Check pricing, browse the rest of the guides and the comparisons, or start from the GogoScreen homepage.

Clarifications

Before you start

Why not just send the client the Replit deployed link?

Some clients will not click it, will not know what they are looking at once they do, or will land on a state that reads as unfinished even when the relevant part of the project is working. A video removes all three risks.

Should the video use the workspace or the deployed app?

Use the deployed route, since that is the actual state of the project a client should be judging progress against, not the development environment behind it.

What if the deployment is only partly finished?

Show the part that works honestly and say plainly what is still in progress. Do not use a workspace preview to make an unfinished part look more done than it is.

Can the video include a flow behind a login?

Yes, with a disposable demo account through the approved process. 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