A launch video makes one claim — the product exists now and does one thing worth a look — and proves it by showing the real product run once, end to end. Sixty to ninety seconds is enough. The two hard parts are keeping the claim to one and finishing by a date that will not move.
Strangers watch launches. They have not read your docs, they do not know your vocabulary, and they will keep exactly one sentence from whatever you show them. An explainer can teach how the machine works because its viewer already decided to care. A launch video only has to establish that the machine exists and deserves a look.
Take a feature-flag platform launching its 1.0. Its video shows a flag flipping on in production, a rollout slider moving from five percent of traffic to fifty, and a bad release rolled back in one click. That platform carries every example below.
Show what it does, not how it works
A launch video shows what the product does and when you would reach for it, with only enough mechanism to make the behavior believable. The viewer sees the rollout slider move and the error graph respond. The viewer does not learn how flag evaluation reaches the edge — the moment a launch script starts explaining internals, it has turned into the explainer that belongs in week two, so save it for week two.
Both kinds of video follow the same craft rules: one idea per scene, real product surfaces, narration written to finished visuals. They answer different questions. The launch answers "what is this and why now," the explainer answers "how does it work," and a video that tries to answer both reads as a demo that keeps interrupting itself with a lecture.
If the launch is happening on Product Hunt, read the gallery guide alongside this one: muted autoplay, skimming viewers, and scrubbed timelines change the cut.
One claim, tested three ways
Every script we produce opens with a single declarative sentence the whole video argues. For the flag platform: you can ship to five percent of your users and take it back in one click. Since the stranger keeps one sentence, pick it deliberately and test it:
- Falsifiable. "Our platform is powerful" fails, because nothing on screen can prove or disprove it. "Ship to five percent and take it back in one click" passes: the video can show it and a viewer can check it.
- Every scene serves it. Any scene that does not push the sentence toward obvious gets cut, however good it looks. Teams bloat launch videos trying to show everything they built; the claim is what gives you permission to leave nine features out.
- A capability, not a count. "The five things our 1.0 does" is a list, a list has no strongest moment, and the count dates the video the day you ship a sixth.
Calibrate the claims while you are at it. If you cannot support "10x faster," write "faster" — or show the timing and say nothing. Your earliest, most skeptical users will verify every claim within the hour, and each uncalibrated adjective is trust debt that comes due on day one.
Plan for half the work arriving after review
In our production records, work done in response to review comes to about half of total effort (the counts). A first pass is half the job, and the calendar should say so from the start. The deadline will pressure you to skip review, and skipping review is the most expensive choice available — so run the cheap gates early:
- Review the scene list before anything is built. Structure failures are free to fix on paper and expensive to fix in render.
- Review two still frames per scene before any motion. Framing errors, fake UI, and wrong surfaces all show in a static frame, at a few percent of render cost (how we learned that).
- Spend the expensive hours last. Two weeks from launch, one full-render-then-reject loop breaks the schedule.
Starting wide helps too. Ten complete candidate cuts judged in a day converge faster than one cut polished for a week, because picking is faster than fixing.
Cut in this order when time runs out
- Cut scenes, never verbs. Delete whole ideas: the worked example goes before the concept, the second angle before the first. Compressing narration into fragments to keep every idea produces captions instead of speech, and it reads exactly as rushed as it was.
- Cut the custom voice. A house voiceover is a solved line item, and recording the founder adds a booking dependency you do not control. It can wait for the director's cut.
- Cut the sound design. Silence beats bad sound. We once shipped a 25-cue effects pass built from stock UI clicks and whooshes; it was rejected wholesale, because perfect integration of cheap assets still reads cheap. A music bed plus narration is a complete launch soundtrack.
- Cut the second video, and say so. The mechanism deep-dive, the feature tour, and the onboarding walkthrough are each a real video with its own claim, shippable after launch. Say what you are not making, so the cut is a decision instead of an accident.
Three things never get cut, at any deadline:
- Real product surfaces. When we built the same topics twice, every rejected take had invented its surfaces and every accepted take used the real ones (the numbers). The audience most likely to watch a launch video knows your product on sight.
- The still review. Five minutes looking at two frames is not where the schedule gets saved.
- The hook and the mute test. Everyone watches the first ten seconds, and most watch them muted, so time saved there is saved on the whole audience. The hook structure is not garnish.
FAQ
How long should a launch video be? Sixty to ninety seconds. A launch claim is a single concept, so it fits (the length math). Past two minutes the video is doing explainer work — split that material out and ship it after launch.
How far ahead of the launch date should production start? Work backward from a first pass being half the work. Three weeks is comfortable, two is workable with disciplined gates, and inside one week you should be cutting scope by the list above, in order.
Should the launch video and the homepage explainer be the same video? They can share a build, but they answer different questions. The efficient path is one set piece and two edits: a launch cut with the payoff front-loaded, and an explainer cut with the full causal chain. A demo and an explainer split the same way.
What if the product isn't finished when the video is due? Show only what is true. A staged feature is a claim the product cannot keep, and early adopters find out immediately. If a feature is not real yet, it is not in the video.
When you're ready, send us your product's URL. We cut twenty short videos of it, and you keep whichever ones earn a full build.