Guide6 min read

Replit Product Hunt Launch Video

One flow, on the live deployment, sized for a gallery scroll.

Scope a Product Hunt launch video for a deployed Replit app, sized for the gallery and tested on the live route.

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

A Product Hunt gallery rewards a video that makes sense in a glance and punishes one that needs context to land. For a Replit app, that pressure runs into a detail many builders overlook until launch week: the video needs to be recorded against the actual deployed app, not the development workspace where most of the building happened. A launch day visitor never sees the workspace. They see the deployment, and the video should match exactly what they will find there.

GogoScreen takes a web app URL and a one line hint, then returns a narrated, edited MP4 with zooms on clicks, cursor smoothing, dead air cuts, and captions. That process works from whatever URL it is given, so the choice of URL is the first and most consequential decision in this whole exercise, well before the hint gets written.

Launch day also removes the usual buffer for fixing a small mismatch after the fact. A landing page video with an outdated detail can be quietly swapped out days later with little cost. A launch gallery entry is largely fixed once the launch is live, and a large share of the traffic it will ever get arrives in the first hours. Getting the source route and the scope right before submitting the render matters more here than it does almost anywhere else this workflow gets used.

Why does the gallery need the deployed route specifically?

A workspace preview can carry behavior tied to development, a different data state, or a build that has simply not been promoted to the live deployment yet. A launch video recorded there risks showing a visitor something they cannot reproduce when they click through from the gallery, which is a fast way to turn an excited visitor into a skeptical one within the first few seconds of trying the app themselves.

Recording source	What launch day visitors actually see	Risk if used for the video
Workspace preview	Not seen by the public at all	Shows behavior visitors cannot reproduce
Deployed route	Exactly what a visitor reaches from the gallery	Correct source for this video
A deployment mid update	A version that may not be stable	Best avoided close to launch day

This concern does not exist the same way for a landing page video, which usually has more time to catch a mismatch before it costs anything, since a landing page gets steady traffic over weeks rather than a single concentrated day. Launch day compresses that margin to almost nothing, which is exactly why the deployment check belongs earlier in the process rather than as a last minute confirmation the night before.

The same discipline applies to the app review walkthrough guide, where a reviewer checking a specific requirement is just as unforgiving of a mismatch between the recorded route and the current build as a launch day visitor is. Both audiences are comparing what they were shown against what they can actually reach themselves.

How do you choose one flow for the gallery?

Pick the single action that would make a stranger understand the product's value in a few seconds, without needing to read the tagline first. Resist the instinct to chain several features together to look more complete; a chained sequence just reads as longer, and length is a disadvantage in a gallery a visitor is scrolling quickly. The strongest choice is usually the one thing about the app that is hardest to describe in words but obvious once seen.

Identify the single most differentiated action the app performs.
Confirm that action is available on the live deployment, not only in development.
Cut any setup or navigation that does not directly serve that one action.
Test the flow muted, since many gallery viewers will never turn sound on.

Compare this scoping problem with the share with a client guide, where the viewer already has context and time. A launch audience has neither, which is what makes the flow choice the hardest part of preparing this asset, and it is worth spending more time on that single decision than on any other part of the process.

What has to be true about the deployment before recording?

Confirm the deployment is stable, reachable, and free of anything that reads as unfinished. A deployed app can still carry placeholder text, an unfilled example state, or a stray debug message left over from development. Launch day traffic is unforgiving of that kind of rough edge in a way a smaller, more patient audience is not.

Give the deployment a short soak period before recording rather than testing it the moment a change finishes deploying. A build can look correct in the first few seconds after it goes live and then reveal a problem once real traffic or a slightly different browsing pattern hits it. Waiting even a short while and rechecking the route once more before recording catches issues that a single early test can miss.

Pick the one flow on the deployed route that best explains the app to a gallery scroller.
Confirm the deployment is stable and free of placeholder content before recording.
Write a hint scoped to that flow and review the candidate well before launch day.

If part of the flow needs a login, a disposable demo account through the approved process is appropriate, and writers should not handle the credential directly. The portfolio demo guide covers a related preparation problem for a reviewer who has more patience than a launch day scroller does, even though the underlying discipline of checking the live route carefully is exactly the same in both cases.

When should the launch video be finished and reviewed?

Finish this well before the public launch date, not the morning of. A render can fail or need a retry, and a deployment can change unexpectedly close to launch in ways that make an earlier recording stop matching reality. Review the candidate muted first, confirm the result is visible on screen without relying on narration alone, and rerecord if anything about the deployment has shifted since the render was submitted.

Treat the days immediately before launch as a freeze window for the deployment, if the team can manage it. A last minute change made to fix an unrelated issue can quietly break the exact flow the launch video depends on, and discovering that after the video is already scheduled leaves very little room to react. A short freeze, even just for the specific route the video shows, removes that risk at a low cost to the rest of the work.

Builders shipping the same asset on a different platform can read the Bolt landing page video guide and the Bolt Product Hunt launch video guide for how the constraints compare there. The choose a web app route for a demo video guide goes deeper on the workspace versus deployment decision covered above, and the short SaaS demo video guide is a useful reference for keeping any launch asset tight. An AI agent bug reproduction video and an automated screen recording for a web app both cover related but distinct recording situations, and a non technical founder demo video is relevant when the person reviewing the launch asset did not build the app themselves. For a comparison with a manual recording tool, read GogoScreen versus Demosmith. Check pricing for how video time works, browse the rest of the guides and the comparisons, or start from the GogoScreen homepage.

Clarifications

Before you start

Should the launch video use the workspace or the deployed app?

Use the deployed route, the one launch day visitors will actually reach. A workspace preview can differ from what is live and should not be used as the launch proof.

How short should a Product Hunt launch video be?

Short enough to work inside a gallery a visitor scrolls quickly. Choose one flow with one clear result rather than trying to summarize the whole app.

What if the deployment changes right before launch?

Rerecord against the current deployment. A launch video tied to an earlier version of the app can show behavior visitors will not be able to reproduce.

How much time should be left before launch day for this?

Enough for at least one retry. Roughly one render in five fails or needs a second attempt, and time is used only on a successful one.

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