How to Make a Product Demo Video: A Practical Maker's Guide

To learn how to make a product demo video, choose one audience, show one complete path from problem to useful result, and end with one next action. Write the scenes before you record, capture the product in short replaceable clips, add narration and accurate captions, then review the finished export against the current product; tools such as OBS Studio, Descript, and Remotion support different parts of that workflow (all checked 18 Oct 2026).

Disclosure: ZeroRaised publishes this guide and is one of the launch options mentioned below. This article makes no claim about the site's audience size, traffic, conversions, or launch outcomes.

TL;DR#

For many makers, the practical route is a scripted screen recording with separate narration. Choose code-generated video when repeatable variants and frequent updates justify maintaining a video project, not merely because code can produce an MP4.

How to make a product demo video in nine steps#

1. Define the viewer and the decision the video should help them make.
2. Reduce the story to one problem, one workflow, and one result.
3. Choose a recording and editing route that fits future updates.
4. Turn the story into a scene table with actions, narration, and evidence.
5. Prepare a clean, realistic, privacy-safe demo environment.
6. Rehearse the product path, then record short replaceable scenes.
7. Record or generate narration that explains the consequence of each action.
8. Edit for comprehension, add verified captions, and export for the placement.
9. Review the video against the released product and connect it to one next action.

This sequence is ZeroRaised editorial advice. It separates product truth from production polish: first decide what must be demonstrated, then choose the least complicated way to show it.

What makers were comparing on 17 Oct 2026#

Recent hook, 17 Oct 2026: Hacker News user loveTech asked how people create demo videos and described the strain of presenting a product in limited time while moving among pages, following a script, explaining the action, and combining recordings with music. Replies pointed to several current routes: ra0x3 said Claude helped create the promo on the Arbi.gg hero after the maker supplied and discussed reference videos; NishanStepak mentioned a Replit-made demo and Loom; and mrieck shared the MIT-licensed DemoDay plugin, which its repository says can script, drive an app, narrate, and assemble a video with Remotion. These are individual maker accounts and product-author descriptions, not comparative tests (Hacker News discussion and DemoDay repository, checked 18 Oct 2026).

The thread is useful because the hard problem was not access to a record button. It was coordinating attention: operating software, speaking clearly, staying within a chosen runtime, and turning separate takes into a coherent story. An AI assistant may take on some of those tasks, but the maker still owns the product state, the claim, the intended viewer, and the final approval. That conclusion is ZeroRaised editorial analysis of the thread, not a measured result.

The available workflows now sit on a spectrum. At one end, macOS includes screen-recording controls and Windows Snipping Tool records a selected part of the screen; Apple documents microphone and click-display options, while Microsoft documents sending a recording to Clipchamp for captions or audio (Apple and Microsoft, checked 18 Oct 2026). At the other end, Remotion represents video as React components rendered over frames, and DemoDay describes an agent-led pipeline that writes, records, narrates, captions, and cuts (Remotion and DemoDay, checked 18 Oct 2026).

The right choice is not the route with the longest feature list. It is the route that makes the current video truthful, understandable, and maintainable with the people and skills available. That is the standard used throughout this guide.

Step 1: define the viewer, placement, and decision#

Do not begin by opening the product at its dashboard. Begin with a production brief. The following fields are ZeroRaised editorial advice:

Placement changes the job. A homepage demo should establish relevance and value, a help-center walkthrough should complete a task, and a sales follow-up can address the workflow discussed with that buyer. One recording can supply clips to each, but the edits have different jobs. This distinction is editorial guidance.

Write the video's decision as a sentence: “After watching, [viewer] should understand [result] well enough to [next action].” If that sentence contains several audiences or several actions, split the work before you write narration.

Also decide what evidence belongs on screen. A product demo is stronger when the result appears in the product rather than only in voiceover. For Arbi.gg, the named Hacker News example, the maker said reference promos helped Claude understand the desired output, but that account does not establish that the same prompting process will work for another product (Hacker News discussion, checked 18 Oct 2026). Use references to communicate visual direction, then make the actual demo prove your own product claim.

Step 2: choose one product story, not a feature inventory#

A useful launch demo can usually be outlined as six beats. This is a ZeroRaised editorial framework, not a platform requirement:

The result is the anchor. Work backward from it. If the final proof is a generated report, determine which source data must be visible for that report to be credible. If the final proof is a deployed change, show enough of the input and output to connect them. Do not replace the connection with a fast montage that hides whether the product did the work.

Cut any feature that does not help establish relevance, mechanism, result, or next action. Put advanced settings, secondary integrations, administration, and edge cases into separate videos when they deserve explanation. A shorter scope is not permission to conceal a material limit. State a limitation when omitting it would give the viewer a wrong impression of availability, automation, price, or required access. These are editorial rules for accuracy.

Use actual interface labels in the scene plan. “Select Create project” can be checked against the release. “Get started instantly” cannot. Verifiable wording makes future updates easier because a changed label or step can be found before publishing an outdated cut.

Step 3: select the production workflow#

Four routes cover most maker situations. The product facts in this comparison come from the linked first-party documentation; the fit guidance is ZeroRaised editorial advice.

Sources: Apple screen recording, Microsoft Snipping Tool, OBS quick-start guide, Screen Studio manual zoom, Loom editing, Descript script media, Remotion fundamentals, Remotion rendering, and DemoDay, all checked 18 Oct 2026.

Choose the simplest route that supports the expected revision pattern. Short screen clips suit targeted replacements; structured components can justify their setup when one dataset must produce many versions; transcript editing helps when spoken delivery dominates the edit. Do not budget from isolated time or cost claims. In the source thread, DemoDay's author gave figures for his own setup and paid services, which is an anecdote rather than a general estimate (Hacker News comment and linked project, checked 18 Oct 2026).

Step 4: turn the story into a recordable scene plan#

A scene plan separates four things that are difficult to manage simultaneously: the interface action, the words, the visual emphasis, and the evidence. Use one row per replaceable unit.

This table is ZeroRaised editorial advice. It turns a vague instruction such as “show onboarding” into a production unit that can be checked and replaced.

Write narration for the viewer, not for the operator. “I am clicking the blue button” duplicates the image. “This creates a private workspace for the client files” explains the consequence, provided the claim is accurate for the recorded release. Use on-screen text for names, brief labels, and transitions; use voice for reasoning that would be clumsy to read while following the interface.

Mark the evidence in every scene. If the narration says an export is ready, show the export or the confirmed state. If it says a teammate received something, show only a safe test account and a real confirmation. If an operation is simulated, accelerated, or completed off screen, label the transition so the edit does not imply a different product behavior.

Create two script columns: must say and can cut. Product identity, necessary context, material conditions, the result, and the next action belong in must say. Decorative adjectives, repeated benefits, and a second explanation belong in can cut. This gives the editor safe places to reduce runtime without cutting the proof.

A compact script pattern#

Use this fill-in structure as editorial scaffolding:

For [specific viewer] who needs to [job], [product] helps [result]. Start with [real input]. Use [essential action] to [mechanism]. The result is [visible output], which lets you [consequence]. [Material condition or limit, if needed]. To try it, [one next action].

Do not record the brackets as marketing copy. Replace each one with language verified against the current product. If the product still requires manual work, do not narrate the result as automatic. If a capability is in beta or restricted by plan, keep that condition beside the claim.

Step 5: prepare the demo environment#

Create a separate demo account or workspace when the product supports it. Populate only the data needed for the story and make it look plausible without borrowing private customer information. This is ZeroRaised editorial advice. “Realistic” means the state behaves like a genuine use case, not that it contains a real person's confidential record.

Prepare the environment with this checklist:

• Use the exact release and access level the narration describes.
• Replace personal names, inboxes, tokens, billing details, notifications, bookmarks, recent-file lists, and unrelated tabs with safe demo content.
• Close applications that can display messages or system banners.
• Set the browser zoom and operating-system scale so labels remain readable at the final embedded size.
• Fix the capture region and window dimensions before recording the first scene.
• Preload only the state that a legitimate user could reach.
• Record the seed data and reset procedure so a failed take can return to the same starting point.
• Keep a text file with names and values that must be typed exactly.

These items are production safeguards, not claims about a specific recorder. The operating system and recorder still determine what can be captured. Apple documents whole-screen, selected-window on supported versions, and selected-portion recording, plus microphone and click-display controls; Microsoft documents selecting a rectangular area for a video snip (Apple and Microsoft, checked 18 Oct 2026).

Record a short technical test before the product takes. OBS explicitly tells users to add or verify sources, check audio meters, and test before the first stream or recording (OBS quick-start guide, checked 18 Oct 2026). For any tool, inspect the test at the intended playback size. Confirm that text is legible, the pointer is visible, microphone input is clean, product sound is intentional, and no private information appears.

Make waiting states part of the plan. If the product genuinely needs time, decide whether the viewer needs to see the full wait, a labeled time compression, or only the completed state. Do not cut from action to result in a way that falsely implies instant completion. That is an editorial truthfulness rule.

Step 6: record clean, replaceable product scenes#

Rehearse without recording until the path is predictable. Then capture scenes separately, including a short still moment before and after the action. Those handles make it easier to cut, add a transition, or let narration finish. This is ZeroRaised editorial advice.

Keep the pointer still when the viewer should read. Move directly to the next control when action resumes. Avoid circling an element or shaking the pointer for emphasis. Use a zoom or callout only when the final viewer could not otherwise identify the control. Screen Studio, for example, documents positioning a manual zoom and adjusting its zoom level after selecting or creating a zoom in the edit (Screen Studio manual zoom, checked 18 Oct 2026).

Record inputs and outputs, not only clicks. A useful scene begins in a recognizable state and ends with visible evidence. If a form submission leads to a result page, preserve the relationship. If you split the action and result into different recordings, match the data exactly.

Name clips by scene and state, such as 03-import-start and 03-import-result. Restart a failed scene instead of forcing later scenes around it. A stitched sequence is legitimate when it accurately represents a workflow a user can perform under the stated conditions. Capture a clean result view after the interactive take, plus any error or empty state the story honestly needs. This is ZeroRaised editorial advice.

Step 7: record narration without narrating the mouse#

Choose one of three orders. The recommendations are ZeroRaised editorial advice:

Speak in complete thoughts that can be moved or removed. Leave a quiet gap between scenes. Keep the subject consistent: either address the viewer as “you,” describe the product in third person, or use “we” only when the speaker's role is clear.

Separate claims from transitions. “The report is ready” needs visible support. “Next, open the report” is navigation. That distinction makes claim review possible and prevents an enthusiastic transition from turning into an unsupported promise.

AI can assist with a first draft, alternate wording, or text-to-speech, but give it verified inputs: audience, actual interface labels, allowed claims, conditions, and prohibited language. Then compare every line with the product. The Hacker News accounts show makers using Claude or other coding assistants for scripting and production, while DemoDay's own repository describes generated narration and word-timed captions; neither source removes the maker's responsibility to review the result (Hacker News discussion and DemoDay repository, checked 18 Oct 2026).

If you use a synthetic voice or presenter, make a deliberate disclosure decision based on the context and applicable rules. This guide does not offer jurisdiction-specific legal advice. At minimum, do not use generated media to imply that a customer, employee, or public figure endorsed the product when they did not.

Step 8: edit for cause and effect#

Build the first cut in story order before adding music, transitions, animated titles, or decorative motion. Confirm that a viewer can answer four questions: What was the starting problem? What did the product do? What result appeared? What happens next? This is ZeroRaised editorial advice.

Then make three editing passes:

1. Truth pass. Compare product labels, plan limits, sequence, and result with the current release. Label any compressed time, composite, mock data, or simulated step that could otherwise mislead.
2. Comprehension pass. Remove cursor travel, setup that the viewer does not need, repeated sentences, accidental pauses, and visual changes unrelated to the narration. Preserve enough context to understand cause and effect.
3. Polish pass. Balance voice, product audio, and optional music; standardize crops; add restrained emphasis; correct captions; and apply the product's current visual identity.

Transcript editing can speed the second pass. Descript says it aligns each transcript word with underlying media, so deleting or rearranging script text also edits the audio and video. Loom documents an Edit by Transcript option for identifying and removing parts of a video through its transcript (Descript and Loom, checked 18 Oct 2026). Those tools change the mechanics of a cut, not the editorial standard for what should remain.

Use transitions to communicate state changes. A title card can mark a new phase, a labeled compression can bridge real waiting, and a zoom can reveal a small control. Every effect should answer a comprehension problem.

Music is optional. If it competes with speech, weakens intelligibility, or creates extra licensing work without helping the story, remove it. Confirm the rights for any track, sound, typeface, stock asset, customer mark, or third-party interface shown. This is general production guidance rather than legal advice.

Add captions and review them as interface copy#

W3C's WCAG 2.2 understanding document says captions are provided for prerecorded audio in synchronized media under Success Criterion 1.2.2, except when the media is an alternative for equivalent text and clearly labeled. It explains that captions include dialogue plus meaningful non-speech audio information (W3C, checked 18 Oct 2026).

Automatic transcription is a starting point. Review product names, people's names, commands, numbers, URLs, interface labels, and specialized terms. Descript documents automatic transcription and text-linked editing; Loom says correcting a transcript also corrects its captions (Descript and Loom caption guidance, checked 18 Oct 2026).

Make captions readable without covering the control or result being discussed. When the placement supports a selectable caption track, provide it. When captions are burned into a social cut, keep the text within the safe visible area for that specific placement. Check the published player, not only the editor preview.

Step 9: export, inspect, and connect the next action#

Keep one high-quality master without platform chrome or a misleading outdated call to action. Derive placement-specific versions from that master. This is ZeroRaised editorial advice. Do not stretch a wide recording into a vertical frame; reframe the important region and check every scene.

For a YouTube upload, YouTube's official guidance lists MP4 as the recommended container, H.264 as the video codec, AAC-LC or Opus among the audio codecs, and says content should be uploaded in its recorded frame rate (YouTube recommended upload encoding settings, checked 18 Oct 2026). Follow the destination's current specification rather than copying an export preset from an old tutorial.

Remotion users can render through Remotion Studio, its command-line interface, a server-side API, or documented cloud and automation routes. Its CLI example uses npx remotion render with a composition selection (Remotion rendering, checked 18 Oct 2026). A reproducible render still needs visual review. Code can consistently reproduce a wrong label, hidden overflow, missing font, or stale screenshot.

Run this final review, which is ZeroRaised editorial advice:

• Watch from start to finish without editing controls visible.
• Watch at the actual embedded width on a phone and a desktop.
• Watch with sound unavailable and confirm captions carry the essential meaning.
• Listen without watching and remove narration that depends on unexplained visual context.
• Pause on every account, notification, browser bar, table, and result to check privacy.
• Click the next-action link from the final page and use a signed-out session when public access is promised.
• Compare every product claim and interface label with the release being launched.
• Ask someone unfamiliar with the script to state the product, intended user, demonstrated result, and next action.

Do not upload over the only master. Keep the approved script, scene map, source clips, caption file, project or code, fonts and licensed assets, export settings, and final file together. Record the product version and approval date. Those records turn the next UI change into a targeted replacement instead of a full reconstruction.

How AI-assisted scripting should work#

Give the assistant a factual production packet rather than the product homepage alone. The packet should contain the target viewer, placement, approved claims, prohibited claims, exact workflow, interface labels, material conditions, desired next action, scene limit, and examples of tone. This is ZeroRaised editorial advice.

Ask for structured output:

1. A one-sentence promise.
2. A scene table with starting state, action, result, narration, and evidence.
3. A list of claims that require product-owner verification.
4. A list of details the assistant could not establish.
5. A shorter cut created by removing scenes, not by making speech unnaturally fast.

That last requirement matters. A model can make a script fit a target by compressing language while leaving too many visual ideas. The better edit is often to remove an entire secondary capability and let the core result breathe. This is editorial judgment.

Use references carefully. In the Hacker News thread, ra0x3 described finding promo examples, asking Claude to describe what it saw, and iterating on the result used on Arbi.gg. The commenter also gave a percentage assessment of completion, but that is a subjective report from one maker and should not be generalized (Hacker News discussion, checked 18 Oct 2026).

When an assistant can operate the browser, constrain its account, permissions, and actions, then review the clicks and exposed data. DemoDay says its agent rehearses before a runner performs a take; that is the project's own description, not proof that every app can be operated safely or correctly (DemoDay repository, checked 18 Oct 2026).

When code-generated video is worth the setup#

Code-generated video is useful when repeatability is part of the requirement. Remotion supplies a frame number and canvas to React code, supports text, image, video, audio, and shape components, and defines a composition with properties such as dimensions, duration in frames, and frame rate (Remotion fundamentals, checked 18 Oct 2026).

That model makes several patterns possible: reusable branded intros, data-driven labels, synchronized callouts, multiple aspect ratios, and batches from structured inputs. Remotion's own showcase names products and projects using it for product videos, instructional content, visualizations, and personalized campaign output, including SuperMotion, Relay.app, Electricity Maps, and GitHub Unwrapped. The showcase is curated by Remotion and should be read as first-party examples, not a neutral comparison of results (Remotion showcase, checked 18 Oct 2026).

Use a coded pipeline when at least one of these editorial conditions is true:

• The same story must be rendered with many legitimate datasets or languages.
• Brand layout and timing must remain consistent across a series.
• Product footage is combined with generated charts, annotations, or other structured visuals.
• Updates arrive often enough that reusable components reduce repeated manual assembly.
• The team already has the engineering ownership to test and maintain the video code.

Prefer a conventional edit when the video is a one-off, the story is still changing, the maker needs to discover the sequence by watching real use, or the maintenance burden would outlive the benefit. These are ZeroRaised editorial recommendations.

A coded render needs the same approval gates as a manual video. Validate inputs, pin or record dependencies, verify fonts and assets, inspect representative outputs, and keep a human sign-off before publication. Test edge cases such as long names, empty data, large numbers, and different caption lengths when those inputs can vary. These are software-production safeguards applied to video.

Turn the demo into a launch asset#

A demo video should lead somewhere accurate. Match the final call to action to the product's actual stage: try the public product, join a clearly described access list, install from the named source, read the documentation, or contact the team. Do not use a generic “get started” when the destination asks for a different commitment.

For a broader release, pair the demo with a launch page that repeats the intended user, product job, access conditions, and next action in text. The product launch checklist covers the surrounding release work, while the Show HN writing guide explains that venue's specific submission expectations. Those internal guides should not be treated as evidence that any venue will produce a particular outcome.

For a Product Hunt release, use the Product Hunt launch guide to align the video with the rest of the listing.

ZeroRaised is built for products made without institutional VC or accelerator equity. If that describes your product and the current submission requirements fit, you can submit your launch free. Review the form and terms on that page rather than treating this article as an eligibility decision. You can also browse the ZeroRaised home board and current maker perks without interpreting their presence here as a promise of traffic, conversion, or acceptance.

Keep the video maintainable after launch. Add replacement triggers to the release checklist beside screenshots and product copy. A renamed control may need one new scene; a changed workflow or promise may require a new script.

Pair the video with the release notes guide when an update needs a durable explanation of user impact, migration steps or breaking changes.

Sources#

• Hacker News, “Survey: How do you create the video demo for your project or product?”, checked 18 Oct 2026
• DemoDay repository, checked 18 Oct 2026
• OBS Studio quick-start guide, checked 18 Oct 2026
• Apple screen-recording guide, checked 18 Oct 2026
• Microsoft Snipping Tool guide, checked 18 Oct 2026
• Screen Studio manual zoom guide, checked 18 Oct 2026
• Loom editing guide, checked 18 Oct 2026
• Loom transcription and caption guide, checked 18 Oct 2026
• Descript script-media guide, checked 18 Oct 2026
• Descript automatic-transcription guide, checked 18 Oct 2026
• Remotion fundamentals, rendering guide, and showcase, checked 18 Oct 2026
• W3C guidance for prerecorded captions, checked 18 Oct 2026
• YouTube recommended upload encoding settings, checked 18 Oct 2026
• ZeroRaised home board, submission page, and maker perks, checked 18 Oct 2026