How to Validate “Is My Product Real?” with a Simple MVP Demo Video

By the end of this guide, you’ll have a short, honest MVP demo video that:

• Proves your product is real and working
• Shows the core value clearly in under 60 seconds
• Avoids deceptive edits that erode trust with users, investors, or YC reviewers

This tutorial is written for founders and indie app builders who want a fast, ethical way to validate “is my product real?” without becoming full-time video editors.

Prerequisites

Before you start, make sure you have:

• A working MVP (even if it’s rough)
  • For apps: something that runs locally or in the iOS Simulator
  • For tools: a minimal flow that completes one real job (e.g., import CSV → generate report)
• A clear value statement (1–2 sentences)
  • Example: “This iOS app turns long standup notes into concise status updates in under 10 seconds.”
• Basic recording setup
  • macOS screen recorder (native or third-party)
  • For iOS apps: Xcode + iOS Simulator
  • Optional: Reely to generate polished reels from simulator footage in minutes
• 5–10 minutes of uninterrupted time

Common failure at this stage: trying to record before the core flow is stable. Make sure the main action you want to show can complete reliably end-to-end.

Step 1: Define “Real” for Your Product in One Sentence

You can’t validate "is my product real?" until you clearly define what “real” means.

Task: Write one sentence that defines your product’s “realness” in terms of a completed job.

Use this template:

"Our product is real if a user can ___ starting from ___ and ending at ___."

Examples:

• "Our iOS app is real if a user can create a new habit, log a check-in, and see streak progress from the dashboard."
• "Our AI report generator is real if a user can upload a CSV and receive a downloadable summary PDF without manual steps."

Why this matters

• Y Combinator explicitly says a rough demo that does something is more valuable than a polished pitch with no demo at all. The gap between "nothing" and "something" is huge.
• Apple’s App Store preview guidelines require showing actual functionality, not implied or imagined features.

Common failure: Defining “real” as vague promises:

• ❌ "Our product is real if it helps teams collaborate better."

Fix by anchoring in observable behavior:

• ✅ "Our product is real if three teammates can comment on the same task and see updates in real time."

Step 2: List the Minimum Honest Beats of Your Demo

Now translate your "real" definition into a short sequence of on-screen moments—your demo beats.

Task: Write 3–6 beats that:

• Start where a new user would start
• End at the value moment (the outcome)
• Only show real, implemented functionality

Beat checklist (MVP demo video):

1. Context beat – 3–5 seconds
   • Show the product surface where a user starts
   • Example: app home screen, tool dashboard, CLI prompt
2. Input beat – 5–10 seconds
   • Show the user providing minimal input
   • Example: filling a single form, dragging a file, tapping one primary button
3. Process beat – 5–10 seconds
   • Show the product doing visible work (even if simple)
   • Example: brief loading state, progress indicator, log output
4. Outcome beat – 5–10 seconds
   • Show the result in the actual UI, not a mockup
   • Example: generated list, scheduled task, summary screen
5. Verification beat (optional) – 3–5 seconds
   • Show one clear way to verify the result
   • Example: clicking into a detail view, refreshing a list, opening exported file

Example script (AI-native iOS app):

• Beat 1: "Start on the app’s home screen showing today’s standup notes list."
• Beat 2: "Tap a note, then tap 'Summarize'."
• Beat 3: "Show a brief processing spinner."
• Beat 4: "Reveal the generated 3-bullet summary inside the app."
• Beat 5: "Open the 'History' tab to show that the summary was saved."

Common failure: Adding beats that imply functionality you don’t have yet:

• ❌ Showing a settings panel that isn’t wired up
• ❌ Using motion graphics to fake a live collaboration view

If it doesn’t exist in your current build, it doesn’t belong in this MVP demo.

Step 3: Write a Simple Voiceover or On-Screen Script

Your demo needs words, but not a movie trailer. Focus on clarity early; Wistia’s 2024 report found instructional videos can reach 74% engagement, far above polished promos.

Task: Draft a 4–6 line script that:

• States the problem
• Shows the core value
• Names what we’re seeing on screen
• Avoids hype and vague claims

Script prompt:

Use this when writing:

"In one sentence, describe what’s happening on screen and why it matters. Repeat for each beat."

Example script (read or captioned):

1. "This is our iOS app that turns long standup notes into short status updates."
2. "Here we tap a standup note and hit 'Summarize'."
3. "The app processes the text locally in a few seconds."
4. "Now you see a 3-bullet summary generated from the original note."
5. "We store each summary so your team can reuse it later."

Honest language checklist:

• ✅ Use descriptive phrases:
  • "Our app processes this text locally"
  • "The summary is generated from this note"
• ❌ Avoid unverified claims:
  • "World’s fastest"
  • "Guaranteed to improve productivity by 200%" (FTC requires evidence for specific claims)

Common failure: Writing script lines that the product doesn’t actually deliver.

If you say it, the viewer should be able to see it in the footage or verify it in the product.

Step 4: Capture a Minimal, Honest Recording (No Fake Shots)

Now you’ll record the flow exactly as a user would experience it. This is where trust can be built—or destroyed.

Apple’s App Store preview rules strongly emphasize:

• Using real on-device footage
• Avoiding transitions or shots that imply features you don’t have

Task: Record one uninterrupted run through your beats.

For iOS / mobile apps (Simulator-based)

1. Open your app in the iOS Simulator via Xcode.
2. Set the window size to match a real device (e.g., iPhone 15 Pro).
3. Use macOS screen recording (or a tool like Reely) to:
   • Start recording before your first beat
   • Perform each beat in order
   • Stop recording only after the outcome/verification beat

For web / desktop tools

1. Open your product in a browser or native window.
2. Hide unrelated windows and notifications.
3. Start screen recording.
4. Run through the beats slowly and clearly.

Recording checklist:

• Show real user input (typing, tapping, clicking)
• Show any loading or processing states
• Do not cut around errors; restart the run if needed
• Avoid overlays that hide the real UI

Common deceptive edits to avoid:

• ❌ Cutting directly from "Upload" to "Result" with no indication of processing
• ❌ Using motion graphics to replace your actual UI with a prettier static image
• ❌ Speed-ramping to hide long delays instead of honestly showing them

If you need polish later, tools like Reely can auto-cut dead air and pace the video without changing the underlying truth of the footage.

Step 5: Trim, Pace, and Keep It Under 60 Seconds

You now have a raw recording. The goal is to make it watchable without crossing into "polished illusion." Remember:

• Wistia’s data across 13M+ videos and 79M viewing hours shows that clarity of key points early matters more than ultra-short length.
• Apple allows up to 30 seconds per App Store preview, which is a good target for many MVP demos.

Task: Trim your recording to a tight 30–60 second demo.

Simple trimming steps

1. Remove the first few seconds before the app is ready.
2. Cut any obvious dead air where nothing happens.
3. Keep the full sequence of beats intact.
4. Do not remove loading states entirely; shorten them slightly if they’re unreasonably long.

Pacing checklist:

• Show the context beat within the first 3 seconds.
• Reach the outcome beat by the 20–30 second mark.
• Keep total runtime under 60 seconds for most channels (Product Hunt, LinkedIn, App Store).

Where to host/share:

• Product pages and homepages typically get the strongest play rates
• LinkedIn is now the primary video-sharing channel for 8 in 10 teams

Video is mainstream for launches: most teams share on LinkedIn, while product pages and homepages drive the best play rates.

Common failure: Over-editing with cinematic transitions, fake zooms, or animated screens that no longer match reality.

Polish is fine; fabrication is not. If an edit changes the viewer’s understanding of what your product can do right now, cut it.

Step 6: Run the "Honest Demo" Checklist Before You Share

Before you send the demo to investors, post it on Product Hunt, or embed it on your site, run this final validation.

Honest MVP demo checklist:

1. Every shot shows real, working product
   • No static mockups pretending to be live UI
   • No concepts or future roadmap features
2. Every spoken or written claim is visible or verifiable
   • Outcome is clearly shown
   • Any performance claims are modest and true
3. No deceptive edited product shots
   • No transitions that imply features you don’t have
   • No “perfect” data sets that hide real constraints
4. Core value is legible in under 15 seconds
   • Problem and resolution are understandable without background
5. The demo matches your current build
   • If users sign up today, they get essentially what they saw

If you want a deeper lens on how high product quality shows up on video, see this related guide: Real product examples: how high product quality shows up in your demo video.

Common failure: Shipping a demo that reflects a beta branch or design prototype, not what users will actually get.

If your demo is ahead of your production build, label it explicitly as "coming soon" and avoid implying current availability.

Bonus: Prompt Templates for AI-Native Demo Generation

If you’re using an AI tool like Reely—or your own coding agent—to generate demo reels from code or simulator footage, you can drive the process with precise prompts.

Prompt for showing core value:

"Generate a 30-second demo reel from the iOS Simulator that shows a user opening the app, running one complete standup-to-summary flow, and viewing the saved summary history. Use minimal kinetic typography to label each step: 'Open app', 'Summarize note', 'View saved summary'. Do not show any screens or features outside this real flow."

Prompt for highlighting the MVP:

"From the latest build artifacts, create a 20-second feature teaser that starts at the main dashboard and shows only the ability to add a task and mark it complete. Focus on the tap-to-complete interaction and the updated progress bar. Avoid depicting settings, collaboration, or notifications that are not yet implemented."

Prompt for avoiding deceptive shots:

"Produce a launch promo from current simulator recordings that includes only live UI footage, real inputs, and actual loading states. Do not use static mockups, concept animations, or artificially sped-up transitions. Keep all scenes tied directly to the existing build."

Using an AI-native tool like Reely, your agent can handle: "build feature" → "record simulator flow" → "assemble demo reel" in one workflow, ensuring the video stays grounded in real code and real UI.

FAQ: Troubleshooting Your MVP Demo Video

1. My product feels too rough. Should I still make a demo?

Yes. Y Combinator explicitly says they value a demo even if it’s local-only or unpolished. The key is that it does something real. A rough, honest demo beats a polished landing page with no product behind it.

2. How long should my MVP demo video be?

Aim for 20–60 seconds:

• Around 30 seconds is ideal for App Store previews and Product Hunt
• Up to 60 seconds can work well on LinkedIn or your product page, as long as the core value appears early

Wistia’s research shows that viewers stay engaged when instructional content is clear, even if it’s slightly longer.

3. Can I use animations or text overlays?

Yes, as long as they don’t misrepresent the product.

• Text overlays that label real actions ("Upload CSV", "Summary generated") are helpful
• Simple zooms or pans over real UI are fine
• Avoid animations that invent screens, buttons, or flows you don’t actually have

4. What counts as a deceptive product shot?

Shots are deceptive when they make a viewer believe the product can do something it can’t actually do today. Common examples:

• Faked real-time collaboration when you only have static updates
• UI mockups animated as if they’re live
• Removing loading states and implying instantaneous performance you don’t have

Under FTC guidance, marketing claims must be truthful and evidence-based—even in software demo videos.

5. How do I keep my demo up to date as I ship fast iterations?

Build demo generation into your release workflow:

• After each major feature, record a new flow
• Use a tool or CI step that can automatically generate reels from build artifacts or simulator sessions
• Replace the video on product pages and App Store listings when the UI or flow changes meaningfully

For AI-native teams, this is where tools like Reely’s agent/MCP integration shine: your agent can recreate flows in the simulator and auto-generate updated promos without manual editing.

Shipping a simple, honest MVP demo video is one of the fastest ways to answer "is my product real?" for users, investors, and launch platforms. Keep the footage grounded in reality, let the value speak through the actual UI, and use light, honest polish to make it watchable—not misleading.