A Product Hunt launch video earns its place when a stranger can say what the product does after one muted viewing. That takes one audience, one problem, one workflow and one next step, usually in 45 to 60 seconds, with real product footage and text that stays readable on a phone. The trade-off is scope, because every feature that does not serve that one task has to go, and cutting your own work is the hard part.
Developers already have the right habits for this. A launch video behaves like a release, with a spec, a build, review passes and a deploy step, and the workflow below borrows all four. The example product is hypothetical, so swap the beats for whatever you ship.
Spec the video in one sentence
Before opening any editor, I fill in this sentence.
For [specific person] dealing with [specific situation], [product] lets them [visible outcome] by [main action].
Take a made-up CLI called driftwatch that compares config between staging and production. Filled in, the sentence says that for backend developers who learn about config drift after a deploy, driftwatch shows the mismatch before release by diffing two environments in one command.
Every spec needs a test, so I write one. After a single muted viewing, a stranger can state the problem and the outcome. Plain words help it pass. A phrase like "environment parity" means little on screen, while two terminals returning different values for the same setting needs no explanation.
The closing action gets decided now too. A video that promises an instant trial should not end on an unexplained waitlist, so I pick the action the product can support on launch day.
Storyboard four beats
The order is problem, product action, result, next step, all following one task from first friction to resolution.
| Seconds | On screen | Text |
|---|---|---|
| 0–6 | Two terminals showing different values for one setting | Same config. Different results. |
| 6–12 | Product name appears over the terminal | Catch drift before the deploy does. |
| 12–26 | Real recording of one command, the diff scrolls in | One command compares both environments. |
| 26–38 | The mismatched key is fixed, the rerun comes back clean | Fix it, rerun it, watch it pass. |
| 38–44 | Hold on the clean result | Checked before every release. |
| 44–50 | Name and a single destination | Try it on a sample repo. |
Running the command and fixing the key get separate shots, each with time to see the action and then its result. Supporting features appear only when the task needs them. Permissions belong in the video if they decide who can approve something, and unrelated analytics can wait for another video.
The on-screen text gets written next to each shot before anything is produced. Every line should describe something the viewer can see, and any number, such as hours saved per week, needs evidence behind it.
Write a style sheet before any motion
A style sheet does for a video what design tokens do for an interface. The decisions get made once and reused in every scene.
I begin with three words for the product and audience. For driftwatch they would be quiet, exact and trustworthy, which points to spacious layouts, legible terminal text and controlled movement. A playful consumer app would pull toward brighter color and looser motion.
Those words guide a small set of references, including my own product screens so the board stays tied to what I am launching. Each reference gets a note about what to take from it.
- Opening clip: Note how fast it states the problem and when the product appears.
- Interface close-up: Note how much surrounding context stays visible around the action.
- Motion clip: Save a timestamp and describe the move, for example the cursor arrives, pauses, then clicks before the camera moves.
A short list of things to avoid helps as well, such as tiny interface text or a new transition on every cut. References get credited and studied for their decisions, while the final compositions stay original. If half the board is quiet and the other half runs on loud effects, I pick one direction.
Next come three still frames for the opening, the main action and the closing card, with the real product in the middle one. I fix one type scale, a small palette from the brand and a repeatable spot for labels, then view all three at phone size. A frame that only works on a large monitor needs a new crop or hierarchy before any animation.
Then I animate a five-to-eight-second test with a product action, a callout and a transition, since those are the pieces that repeat. A few written rules sit beside it.
- Timing: Let each label be read before the next change, and let each result register before cutting away.
- Easing: Let panels settle smoothly, and save bounce for a deliberately playful tone.
- Continuity: Keep a shared object in a similar screen position across a transition.
- Restraint: Reuse a small set of cuts, and keep the boldest movement for the main reveal.
Rege (@rege_dev) shared a motion graphics pass on X that works as a reference when writing rules like these.
When a move feels wrong, I shorten its distance or remove it before adding another effect. Once the sample works, it becomes the reference for every remaining scene.
Keep each shot to one idea
Reading a headline, tracking a cursor and parsing three animated cards at the same moment is too much for a viewer. For each shot I pick the place the eye should land first, move toward that control, then hold still while the action plays and the result settles. Crowded scenes usually respond to one of these fixes.
- Three feature cards arrive at once: Show only the feature the current action needs.
- A full dashboard shrinks the key detail: Crop closer while keeping enough context to recognize the screen.
- A paragraph sits over moving footage: Cut it to a short label and spread the idea across shots.
Narration is optional, but any narration needs accurate captions.
Capture the footage and gather assets
The storyboard produces the asset list. For driftwatch that means a screen recording of the real command, two staged terminal states, a logo and a closing card, with no generated footage needed.
A demo account with sample data, closed tabs and silenced notifications makes a cleaner recording. I record in short takes with a pause before and after each action, and I label any section where I trimmed loading time if speed is part of the claim. Screen Studio on macOS offers adjustable zooms, and any existing screen recorder works too.
Music stays in a supporting role. The YouTube Audio Library separates tracks that need attribution from those that do not, so I copy any required credit into the description and check the terms before reusing a track in social or ad cuts. A track being available inside a tool does not clear it for every use.
Generated footage is for illustration only, such as a setting or an abstract transition, and never a stand-in for a working feature. Runway's image-to-video guide separates the image's composition and style from the prompt's motion instructions, so I ask for one slow move and keep exact text and logos in the editor.
CoAnimator's plugins cover voice, effects and music through ElevenLabs Audio, images through Gemini Images, and images and video through Grok Imagine. After enabling one and finishing its key setup, I start a fresh agent session so the change is picked up. Provider usage is billed through the provider account, and credentials stay in plugin setup. Real product footage comes from a separate recorder and gets imported.
Build the cut with an agent
With the story and assets ready, the CoAnimator quickstart covers connecting an agent and opening a project. I hand over the scene plan and approved files together and ask the agent to list missing footage before it builds anything. Here is a Product Hunt launch video made in CoAnimator.
A starting brief, to be adapted.
Build a 50-second, 1920x1080 launch video for driftwatch, a CLI that compares config between environments. Use the attached logo, brand font and screen recording. The promise is catching config drift before a deploy. End on "Try it on a sample repo."
Follow this timing: 0–6s mismatch, 6–12s product name, 12–26s the command and the diff, 26–38s the fix and a clean rerun, 38–44s hold on the result, 44–50s closing card.
Match the attached moodboard, style frames and motion test: quiet, exact, trustworthy, one accent color. The story must make sense without audio. Keep text layers separate from footage so they stay editable.
Do not invent commands, output, customer logos or statistics. List any missing assets before starting. When revising one shot, leave approved scenes untouched.
The loop after the brief is describe a change, watch it land on the stage, redirect. Rege posted a demo of that loop as an alternative to traditional motion tools.
The review runs like code review. I start with an animatic, which is the storyboard frames held on a timeline with rough timings, because a missing step or a weak opening is cheapest to fix there. After that, the full cut gets one pass at a time.
- Design: Is the key detail obvious in every frame?
- Motion: Is there time to read each label and register each result?
- Sound: Do speech, music and effects share one rhythm?
- Finish: Does the export keep the intended result, with correct captions, unclipped text and clean audio endings?
Within a pass I change one thing at a time, compare it with the previous version, and keep or revert. CoAnimator keeps projects as editable, git-friendly files, so committing each approved state makes reverting trivial. Feedback to the agent works best as a timestamp, an observation and a specific change.
At 00:28 the clean-state label appears while the camera is still moving. Let the camera settle, then show the label and hold it for two seconds. Leave the surrounding shots alone.
Acceptance criteria get written before the final review, so the work stops when the cut passes the stranger test and every further change solves a named problem. For export, a 1920x1080, 16:9 master is a practical choice for a readable software demo, at 30 fps or matching the recording. Those are production choices and not Product Hunt requirements.
Re-render instead of rebuilding
A launch video goes stale the moment the interface changes, and the editable project is what makes that cheap. For a later release I swap the changed screens and re-render instead of reconstructing the sequence from an exported file. The Coa CLI renders headlessly from scripts, cron jobs or CI pipelines, so a release-day re-render can run without anyone opening the app.
Test it on someone who has never seen the product
The exported file gets one viewing by a person who knows nothing about the product, with no introduction first. I ask four things. Who is it for and what problem does it solve? What did the product actually do? Where did you need more time? What would you do next?
Specific points of confusion beat opinions on production quality. Someone who remembers the animation but cannot explain the workflow means the sequence needs simplifying. Someone who understands the problem but doubts the result means the product evidence is thin. When two openings are competing, I make both with the rest of the cut held constant and ask what each one leads them to expect.
Before launch I also confirm that text and controls are legible on a phone, that every demonstrated feature exists, that no private customer data is visible, and that captions and credits are correct. After launch, the numbers worth watching are the ones tied to the video's job, such as sample-project starts or signups, because upvotes alone say little about whether the video worked. CoAnimator has no built-in analytics, so that tracking comes from YouTube and the product itself.
Get the video to show up on Product Hunt
A passing cut still has to appear on the listing. Product Hunt's posting guide treats the video field, the gallery and the thumbnail separately.
- Video field: Needs a full YouTube URL, since shortened links are not supported, and the video cannot be private.
- Gallery images: Recommended size is 1270×760, and at least two images are needed for the gallery to display.
- Thumbnail: Recommended square size is 240×240, and GIFs must stay under 3 MB.
The gallery size describes still images and has nothing to do with the video canvas, so I export the video separately and paste its YouTube URL into the listing.
Uploading at least a day early gives a buffer. Product Hunt's YouTube troubleshooting guide says a fresh upload may need about 12 hours before the integration works, and embedding restrictions can also block it. I open the link while logged out, then play it inside the draft preview, because a working watch page does not prove the embed works.
What to build after the launch video
The launch video is rarely the last one. Because the project stays editable, the same files can feed a 15-second cut for social, a short clip for every release, or a refreshed demo whenever the interface changes. Keeping the style sheet beside the project means each new video starts from a settled look instead of a blank timeline.
The ceiling is higher than screen recordings. Rege shared a 3D keyboard scene that shows how far a describe-and-direct loop can go when a product deserves more than a UI demo.
The quickest test of all this is to record one real product action and run it through CoAnimator with your own coding agent. A rough first cut will show whether the storyboard holds up.
Top comments (0)