How to Make a Demo Video for Your SaaS Without a Camera
Every shot you need is already on your screen. A practical way to turn a working feature into a demo video people actually watch.
Search for "how to make a demo video" and you get lighting diagrams, lavalier mic recommendations, and someone explaining the rule of thirds. None of it applies to you. Your product is software. There is nothing to point a camera at.
The good news is that every shot you need is already sitting on your screen. The hard part was never filming. It is deciding what to show, in what order, and what to leave out.
Here is a way to do that with a screen recorder and about two hours.
First, decide what this video is not about
The most common mistake is trying to cover the whole product in ninety seconds. You end up with a tour: here's the dashboard, here's settings, here's the integrations page. Tours are the least watched kind of product video, because a tour asks the viewer to hold six things in their head and gives them no reason to care about any of them.
Pick one question instead. Not a feature — a feature is not a selling angle — but a question a real person has asked you.
- "How is this different from just using a spreadsheet?"
- "How long does it take to set up?"
- "What does it actually do with my data?"
- "Does this work if my team is on Slack, not email?"
One video answers one question. If you have four questions, that's four videos, and each one is easier to make than the single video that tried to answer all four. It's also four things you can post on four different days, which matters more than it sounds.
Write your question at the top of a note before you record anything. If a shot doesn't help answer it, it doesn't go in.
Three structures that work with screen recording
1. The one-task run-through
Show one complete task from start to finish, in real time, with nothing skipped. This is the video form of the how-it-works angle — you are showing the mechanism, not claiming it.
This works because software buyers are pattern-matching against their own workflow. They are not evaluating your UI. They are asking "would this fit into my Tuesday?" A complete run-through answers that; a montage of pretty screens does not.
Say you built a tool that turns customer support tickets into a weekly summary for the product team. The run-through:
| Shot | What's on screen | Length |
|---|---|---|
| 1 | The messy input — a support inbox with 60 unread tickets | 3s |
| 2 | Connecting it, one click, no config screen | 4s |
| 3 | Waiting state, unedited — this is the honest part | 2s |
| 4 | The finished summary, scrolled slowly top to bottom | 8s |
| 5 | One specific line in the summary, zoomed | 3s |
Twenty seconds. Notice shot 3. Most founders cut the waiting state, and it's a mistake — leaving in two seconds of "it's working" is what makes the rest look real rather than mocked up. If it takes four minutes, then speed it up and put a timer on screen, but don't pretend it's instant.
2. The before/after split
Two recordings side by side: the old way on the left, your way on the right, both starting at the same moment. The reasoning behind it, and the ways it goes wrong, are covered in the before / after angle.
This is the highest-conviction structure available to you, and it's underused because it requires you to actually record the old way. That means genuinely doing the task in a spreadsheet, or across three browser tabs, or however your users do it now. It takes an extra twenty minutes and it's worth it, because the contrast does the arguing for you. You don't need a voiceover claiming you're faster. The left side is still going when the right side is done.
Rules that make it work:
- Both sides start at zero. No pre-filled state on your side.
- Don't sabotage the left side. If you fumble the spreadsheet on purpose, people can tell, and you lose them permanently.
- Let it run to the real end. The moment the right side finishes and the left side is still going is the entire point of the video. Don't cut away from it.
3. The objection answer
Open by naming the thing they're worried about, then spend the rest of the video showing it isn't true. When the worry is a belief rather than a doubt about your product specifically, the myth-busting angle is the sharper version of this.
The objections worth building a video around are the ones you've heard more than twice. For most developer-facing products they're some version of: migration will take a week, my data will end up somewhere I can't see, it'll break when we hit real volume, my team won't adopt it.
Structure:
- State the objection as a sentence on screen. Plain text on a plain background. "Most of these tools want you to move your whole workflow first."
- Cut straight into the counter-evidence. Not a claim — a recording. If the objection is setup time, show the clock. If it's data control, show the export button and the file that comes out.
- End on the state that proves it. The imported workspace, the downloaded file, the passing test.
This one converts well and almost nobody makes it, because it requires admitting out loud that people have reservations.
Recording so it doesn't look amateur
Four things account for most of the difference between a demo that looks credible and one that looks like a screenshot with a mouse in it.
Use real-looking data. This is the big one. test123, asdf, Lorem ipsum, [email protected], and a customer list that reads Aaa, Bbb, Ccc — these tell the viewer that nobody has ever used this product. Spend fifteen minutes seeding an account with plausible names, plausible numbers, plausible dates. A dashboard showing $0 across every metric undoes an otherwise good video.
Shrink the window before you record, not after. Record at a smaller browser window (around 1280 wide) so your UI is legible when the video is played at phone size. If you record a full 4K desktop and scale it down, your 14px labels become unreadable mush, and there is no fixing that in the edit.
Slow your cursor down. Move deliberately, pause a beat before each click, and don't wiggle while you think. Fast erratic cursor movement is the single clearest tell of an unrehearsed recording. Do a silent practice run first — you'll be surprised how much it tightens.
Record more than you need at the start and end. Two extra seconds of handle on both ends of every clip. It costs nothing and it's the difference between being able to cut on a clean frame and being stuck with a clip that starts mid-motion.
The first three seconds are a different job
Most of a product video's audience is decided before the third second. On a feed, your video is competing against a thumb, not against other products.
What doesn't work as an opener: your logo, a title card, "Hi, I'm the founder of…", a slow fade into a dashboard.
What does: the finished result, out of order. Start with the thing your product produces — the generated report, the cleaned-up inbox, the passing build — and only then go back and show how it got there. You're spending your best frame on the payoff rather than saving it for an ending most people won't reach.
The second-best opener is the problem state, if it's visually obvious. A screen with forty-seven browser tabs open reads instantly. A spreadsheet with six colors of highlighting reads instantly.
Subtitles are not optional
Most of these views happen with the sound off. If your video depends on a voiceover, and most of your audience never hears it, then your video is a silent film with a confusing plot.
Two implications:
- Every claim that matters has to appear as text on screen, not only in narration.
- Keep on-screen text to a handful of words at a time and leave it up long enough to read twice at normal reading speed. Text that flashes by faster than it can be read is worse than no text, because it registers as noise.
If you write the on-screen text first and record to fit it, the video usually comes out tighter than if you narrate freely and add captions afterward.
Where people usually go wrong
Explaining the interface instead of the outcome. "Over here on the left you'll see the navigation panel" is a sentence for a training video, not a demo. Nobody is buying your navigation panel.
Music that's louder than the point. If the track is doing emotional work your product isn't, viewers feel the mismatch even if they can't name it. Quiet or nothing beats an epic build under a CRUD app.
One video, endlessly polished. Five different angles on the same product, each rough, will teach you more about what lands than one video you've re-edited eleven times. You cannot predict which framing works — the objection video you almost didn't make is frequently the one that gets shared.
Ending without a next step. Not a hard sell. Just say plainly what to do: the URL, "free while it's in beta," "reply if you want an invite." A demo that ends on a fade to black wastes the attention it earned.
A reasonable first pass
If you have a working product and one afternoon:
- Write down the three questions you get asked most.
- Record a one-task run-through for the first one. Twenty to thirty seconds.
- Record the same task the old way, and cut a before/after from the two takes.
- Record an objection answer for whichever worry comes up most.
That's three videos from roughly one afternoon of recording, and they're different enough to post on different days to different audiences rather than being three edits of the same thing.
Then watch which one people actually finish, and make more of that one.
Angles turns a product brief into a batch of these — different structures, different openings, all rendered and ready to post. If you'd rather record them yourself, the structures above work exactly the same.
Related Articles
A Feature Is Not a Selling Angle: One SaaS, Twelve Different Videos
Your feature list is a set of facts. An angle is a claim someone can disagree with — and that difference decides whether your launch video lands.
TutorialWhat to Post on Launch Day: A Video Checklist for Indie Makers
Launch day needs five or six different videos, not one good one. Here's what each channel actually wants, with lengths and openings.