Most "promote your project with a demo video" advice treats it as one video made once. It's really a different cut for every moment attention shows up — README, launch day, a CFP — and in at least two real situations, video is the wrong answer entirely.
"Make a demo video" shows up on almost every open-source launch checklist, filed next to "write a good README" and "pick a license," as if it were one asset you produce once and reuse everywhere. It isn't. A README embed, a Show HN post, a conference CFP, and a sponsorship pitch are four audiences arriving with four different amounts of trust already extended, and a demo video earns its place in some of those moments, does close to nothing in others, and can't substitute for a couple of things at all. Worth sorting those before spending an afternoon on the "official" project trailer.
The instinct behind "make a demo video" is usually "nobody's finding my project." A demo video doesn't fix that. Nobody searches "demo video" to discover a CLI tool or a library — they search the problem, land on a README, a Show HN thread, or a link someone shared, and only then decide whether to keep reading. What a demo actually does is shorten the gap between "I'm looking at this" and "I believe it does what it says," for someone who has already, for whatever reason, shown up. That's a real and useful job. It is not a discovery mechanism, and a video posted where nobody is looking converts nothing.
A GitHub visitor decides in seconds, and a wall of badges plus a prose description doesn't show the moment that actually sells the project — the command running and the real output appearing. That's why the best READMEs already lead with a short looping clip of the tool doing its thing, and it's the exact case turning a README into a demo is built for: the install step as a typed terminal, the quickstart as a real code card, grounded in the repo's own docs rather than a generic voiceover.
One honest shape mismatch worth naming here: a README's code column is wide, and the demo clips that live there are conventionally landscape — closer to a terminal recording's native shape than a phone screen's. Our own studio renders 9:16 by default, the shape a YouTube Short or an Instagram Reel actually needs. That's the right shape for the narrated walkthrough you post to X or Reddit; it's the wrong shape to force into a README's own inline hero slot, where a plain landscape terminal recording still fits the column better. Use the vertical cut for the surfaces built for it, and keep the README's own loop landscape.
Hacker News is text-culture. A video attached to the Show HN post itself gets skipped by most people scrolling the front page — the post has to sell itself in words. A video linked from inside the README, one click deeper, still helps: it's there for the subset of readers who get past the headline and want to see the thing work before they clone it.
Product Hunt is the opposite case, and it's the one launch venue where a properly produced demo pays off directly — PH visitors expect media in the gallery before they read anything, and a project with no video in that slot looks unfinished next to ones that have it.
r/opensource and r/programming sit closer to HN's culture than PH's: the post text still has to carry the pitch, and the video becomes the answer to "does this actually work," linked in a comment rather than autoplaying in the post itself. Same asset, three different jobs depending on which door someone walked through.
The same logic we wrote up for DevRel teams applies to a solo maintainer just as directly: a video per release note, attached to the release cadence you already have, beats a single "official" trailer that goes stale the moment a flag gets renamed underneath it. A baked recording means a full re-record for one changed command; a project built from editable scenes means updating the one line that changed and re-rendering — the same argument the README post already makes about the project's own docs, applied to every release after the first.
A conference organizer reading two hundred CFP submissions has almost nothing to go on beyond an abstract that reads like every other abstract. A linked 60–90 second recording of the tool actually running — attached to the submission, not required, just available — is cheap insurance against "we couldn't tell if this talk would hold a room." It doesn't replace a good abstract, and a bad talk idea with a slick demo is still a bad talk idea. But among two similarly-argued proposals, the one an organizer can watch for ninety seconds has a real edge, and almost nobody submitting a CFP bothers to attach one.
Three real cases, stated plainly rather than glossed over:
Purely illustrative — not a real project or customer. Say a CLI tool is launching this week. The README gets a silent, landscape, ten-to-fifteen-second loop of the install command and one real command producing real output — muted, since GitHub's own preview autoplays without sound. The Show HN post carries no video at all; the text does the selling, and the README's loop is one click away for whoever gets that far. A sixty-to-ninety-second narrated walkthrough — the shape a vertical Short is actually built for — goes to r/opensource and X, for the audience that wants to be convinced before they clone it. And the next release, a month later, gets its own forty-five-second cut built the same way, not a new production from scratch. Four different jobs, four different shapes, one script structure reused across all of them.
If your next release needs the narrated-walkthrough cut rather than the README's own landscape loop, the README-to-Short maker grounds the script in your actual docs, and if the interesting part of your project lives in a terminal, the terminal demo maker types the real commands instead of recording a screen that goes stale the moment a flag gets renamed — the same durability argument that made terminal recording tools worth comparing honestly in the first place.
Get one practical MCP-video tip when we publish the next post — no more than that.
Point your agent at a video pipeline that speaks MCP and make one small thing. Free founding-creator pilot — your keys, no watermarks.
Create your studio — free pilot