Agencies charge $5,000 for a 60-second product demo video. I make mine for $0. Here's the exact workflow.

That was the thing that changed how I thought about it. A traditional video is a snapshot that decays. The HTML file is a template you update. When Flowly's UI changes I'm not going back to an agency or re-recording — I'm opening the same conversation and describing what changed. The asset stays current for the cost of a prompt.

Thanks — the believability piece is basically “show constraints.”

What made me trust the workflow wasn’t the $ line — it was reuse (same asset class you can refresh when the UI moves) plus doing it multiple times so I wasn’t overfitting a lucky first output. Speed-to-“not embarrassing” mattered more than perfection.

Cost was a bonus; compounding was the real signal. Distribution staying hard was the anti-magic reminder.

The scene description being the bottleneck is exactly right, and it's actually the correct bottleneck to have. That's the creative work — knowing what you want to show and in what order. Once that's clear Claude handles the execution. The founders who struggle with this workflow usually haven't written a proper script before prompting. They describe a vibe instead of a sequence and the output reflects that. Glad the iteration loop felt fast — that's the part that surprised me most the first time too. What product were you demoing?

They mostly won’t stick around — you get a tiny scroll-by audition. Long works only when second 1–2 buys second 3+ (clear “for me,” tension, or payoff teased immediately).

Builders judge explanation; viewers judge relevance + novelty. Same clip can feel brilliant internally and invisible publicly.

Learn from drop-off in analytics, rewrite openings more than the whole demo, and show hooks to people outside your niche — they’ll expose the angle problem fastest.

Love the “assets as software” framing — that’s the same mental model shift as treating demos like a living file, not a marketing deliverable you freeze at export.

And you’re dead right on the second unlock: before-it-exists storytelling is brutal with live capture, but it’s natural with a stunt double — comparisons, “here’s the flow we’re shipping,” teaser beats… you’re directing pixels toward an intended future, not waiting for the build to behave.

The only guardrail I’d add in public is boring but important: label aspirational stuff honestly (teaser vs shipped) so trust doesn’t get collateral damage when the timeline slips.

But as a creative surface area, synthetic UI is basically cheat codes for roadmap and category narratives — totally agree.

Appreciate that — and I agree with the reframe: budget stops being the excuse pretty fast; what still separates demos is clarity of story and how quickly you can ship iterations.

The stunt double + reprompt combo is basically “lower friction per cut,” which lets you test hooks the way you’d test landing copy.

Good luck with whatever you’re building — hope the workflow saves you a few painful reshoot days.

Small HTML demos can work on lower tiers if you paste the UI context yourself, but Claude Design (the automatic design-system extraction piece) is Pro+ in my account — so budget for that if you want the “read my codebase” shortcut.

Storytelling vs documentation is exactly the divide — a demo is a translation layer, not a user manual. “Live capture” tends to be an ego thing for the builder; viewers mostly want instant comprehension + conviction.

I also buy the separation framing: your real app earns trust by not crashing on Tuesday; your stunt double earns attention by not wasting a second on chaos that doesn’t teach anything.

On desensitization: yeah — polish becomes table stakes the same way nice landing templates did. The “perfect UI” look will stop feeling magical and start feeling normal, especially as more people use similar workflows.

But I don’t think people get tired of clarity — they get tired of generic stories. The fatigue lands when every video is the same cadence, same hook, same fake dashboard energy with nothing to say.

So long term: distribution and taste still dominate — audience building, positioning, offers, repetition. AI mostly raises the floor and speeds iteration; it doesn’t magically solve “why should I care” if the story’s thin.

That framing maps perfectly to iOS too — camera wants control, and simulators/devices keep giving you unhelpful honesty (keyboard timing, fake data reads fake, touch rings miss by a hair).

For me it’s been web/HTML stunt doubles in practice, because that’s the easiest “director’s cut” surface for scripted motion. I haven’t gotten to a native-native version I’m happy with yet.

The CSS-over-previews hack is clever, but you’ll usually keep seeing the “almost real” seam — previews still ride the real layout/animation pipeline.

Where I’d go next on mobile is the same principle as the post: recreate the UI as a controlled performance (often easiest as HTML that mimics iOS chrome), or micro-clips + stitch so you’re not fighting one uncut take.

If you find a workflow that closes the quality gap cleanly, I’d love to hear what you shipped — iOS is the harder version of this problem.

Exactly — dashboards are the worst offenders because “truth” and “camera truth” diverge: a late fetch, a blank series, or one outlier scale change and the whole take feels broken.

The stunt double trades honest entropy for directed signal, which is annoying philosophically but perfect for a 20-second explanation.

Yeah — the trap isn’t money, it’s infinite scope with one calendar.

The only scaling lever I’ve found that actually holds is turning demos into a repeatable pipeline with a hard timebox (script → artifact → record → ship), and refusing to chase perfection on any single cut. Batch hooks, reuse stems, and treat weekly shipping as the default — burnout usually shows up when each video becomes a “special event” instead of a release ritual.

This is a great read — and you’re coming at it from the side of the stack where the calendar tax is even more brutal (cue notes, stems, approvals, “locked picture,” then picture moves anyway).

You’re also right that the headline price isn’t what hurts; it’s latency disguised as professionalism — meetings, queues, rounds — and by the time a vendor catches up, the product is already telling a slightly different story.

I love the “versioned footage” phrasing even more than “free,” because it matches how I actually work: marketing stops being a deliverable milestone and becomes something you can merge forward.

The only moat I’d append (slightly boring, but true) is that iteration speed amplifies taste — fast plumbing still won’t save a fuzzy story — but on timing and freshness, you’ve nailed the asymmetry vs the agency model.

Rooting for DropCue — music tooling needs more of this “iteration-first” energy.

Love this — we’re aligned on the bigger point: the budget line moved, even when it’s not literally zero.

Your stack is a nice hybrid too: ScreenFlow for the “real interaction” spine, Grok Imagine for quick visual detours, ElevenLabs for VO, Canva for the last 10% polish — that’s basically “iterate like a creator, price like an indie.”

If you ever hit the classic pain (loaders, flaky states, endless retakes), the HTML stunt double is another knob — but for a lot of founders your workflow is already 80% of the win.

Keep treating marketing videos as a creative outlet — that energy shows in the cuts.

Totally agree on the moat — cheaper production mainly means you can try more hooks per week, not that any single video carries you.

On the five cuts: too early for a clean “winner format” on my side — small sample, cold account, and shorts algo noise drowns a lot of signal. Anecdotally, the ones that felt strongest were single-beat clarity (“watch this one interaction land”) vs lifestyle/PV vibes, but I won’t pretend I have statistically meaningful readouts yet.

The variant-testing point is real though: with a stunt double you can reskin pacing/cropping/copy without another filming day — so the right experiment loop is hooks, not render quality.

Appreciate that — you’re right that making the thing and getting it seen are two different skillsets, and I’m absolutely still climbing the second hill.

I’m not taking a bunch of “growth strategy” calls right now, but if you want to send a quick note with what you specialize in (channels, playbook, typical stage) I’m happy to skim it. If there’s a clean overlap and timing fits, we can figure out a low-friction next step.

Either way, thanks for reading the post.

You’re pointing at the part that still separates “cool workflow” from “business leverage.” A demo that looks great but doesn’t change behavior is just expensive vanity without measurement — and you’re right that most founders stop at shipping the asset.

What I’m tracking today is still fairly crude (trial starts / activation-ish signals), and I won’t pretend I’ve nailed watch-depth → signup correlation yet. The experiments you listed — embed vs thumbnail, video-first vs text-first, which beat loses people — are exactly the right next layer once production stops being the bottleneck.

Thanks for sharing the SQL handbook — funnels get messy fast once you add multi-step events, and having sane query patterns helps a lot.

Yeah — cadence is the hidden tax. One great video doesn’t move the needle if you can’t ship again next Tuesday without a crisis.

“Reprompt not reshoot” is what turns marketing from a hero asset into a release ritual: same story bones, fresh UI, fast polish. That’s the solo-founder version of a content team.

The part I’m still honest about: you can make weekly output realistic and still need distribution discipline — but at least you’re no longer blocked on “another recording session.” Congrats on pushing SocialPost.ai forward.

That reframe is the whole thing — ground truth for shipping vs ground truth for camera are different, and mixing them is what makes real recordings expensive.

On the landing-page angle: I haven’t shipped the embed everywhere yet, but I buy the logic — a lightweight HTML “hero replay” can feel more alive than a static mock if you keep it tight (file size, no mystery third‑party JS, and something sane for reduced-motion users).

For timing: I stopped asking for vibes and started asking for a timeline. Not usually frame counts — seconds + milestones is enough (“0.0s idle, 0.35s typing starts, 1.1s chip animates in, 1.6s card drops, hold 0.4s”). If something feels floaty, I don’t get more poetic — I get more mechanical (“ease-out, duration 220ms, overshoot 6px on cursor landing, 80ms pause before click”). Claude handles that really well once you’re specifying when things begin/end, not “smoothly.”

If you want a rule of thumb: keyframes in time, not adjectives; add easing only after the sequence is right.

Thanks ;)

Love that you’re connecting those dots — both are basically “scripted UI motion,” just with different goals.

Playwright/Chromium is for proving the real app; the stunt double is for camera-safe storytelling. The hybrid I’ve seen attempted is golden-path E2E on staging + screen recording (deterministic data, tight waits) — more “real,” but you still fight flakes unless the env is boring.

For marketing polish, I’d still default to the HTML replay; for trust/debug video, tests-to-footage is interesting if you accept some rough edges.

If you prototype a stitch workflow, I’m curious what you land on — it’s an under-explored middle.

Exactly — $0 is the skim; reuse is the reframe.

A one-off video is a photo that starts aging the minute you export. A stunt double you can regenerate tracks what you’re actually shipping, so marketing stops fighting the product calendar.

If you try it, the habit that pays off fastest is versioning the “master” like code: same story structure, updated UI context — reprompt beats reshoot every time.

Yeah — I’d narrow the word “useful” slightly: for shipping actual value, the real product still wins. For communication (short-form, landing hero, previews), controllability beats fidelity.

“Simulation over recording” is exactly the right metaphor: you’re building a physics-off version that performs the story reliably, instead of hoping the live app cooperates as a performer.

That mindset shift is half the unlock; the tools are just what make it cheap enough to iterate weekly.

Appreciate you spelling it out this cleanly — you captured the whole arc without losing the “stunt double” / “reprompt not reshoot” punchlines.

The only nuance I’d add for anyone reading the summary: $0 is mostly “incremental tool spend” if you already have the AI subscription — the real cost is still script + iteration time. But the economic shift you named is the important one: it stops being a brittle marketing project and becomes something you can refresh on the same cadence as shipping.

Thanks for sharing the workflow forward.

Thanks — if you try it on anything you’re shipping, the part that usually “clicks” is scripting timing beat-by-beat instead of asking for “smooth.”

That’s a really sharp parallel — App Store preview footage is basically made for the stunt-double trick because Apple wants polish, but a live iOS build still has physics (latency, layout passes, “almost loaded” frames).

On re-prompting: I don’t rely on “it’ll just know” from vague memory of last week. I re-paste what actually moved — usually the key screen components + whatever defines tokens (Tailwind theme, CSS variables, a small tokens file). If your design system is scattered, a single canonical token block (colors/type/radius/shadows) is worth keeping: it’s 30 seconds to paste and it prevents 20 minutes of hue drift.

So: codebase context works when you feed it, not because it magically tracks main. The workflow is less “one permanent snippet forever” and more tiny pinned header of tokens + the files for the screens you’re animating, refreshed when those change.

Glad it resonates.

Pretty well if you don’t ask for one file to be your whole app: multi-step flows and modals work best as timed scenes you stitch, with explicit beat-by-beat timing in the prompt. Dense tables need a “camera edit” (fewer columns, clearer rows) so it doesn’t turn to mush on a phone screen. Real branching logic is the hard part — for demos I script one golden path on rails instead of simulating every state.

Appreciate the kind words — and I’m sorry about the six-month detour. That kind of bruise is annoyingly educational: you don’t need more hustle, you need earlier signal.

You’re right on the ordering too: a slick demo of the wrong thing still loses. I care a lot about keeping Flowly pointed at problems people already feel weekly — if we ever ship something that’s more “cool” than useful, that’s on us.

I’ll take a peek at TrendyRevenue when I’m in idea-testing mode for the next experiment; source-cited gaps + “why this niche” is the part I’m usually skeptical of unless it’s concrete.

Thanks for the follow — agreed the early grind is mostly normal, even when the timeline makes it feel like it isn’t. Keep building.

Building a CRM before you have a live product is actually the smart move, you already know what the demo needs to show before the real thing exists. The HTML stunt double workflow Max described is perfect for exactly this stage.

Pre-launch is one of my favorite use cases for this — you’re not “faking a product you have,” you’re staging the story you’re about to build, without waiting for auth, data, and edge cases to cooperate.

For ElevenLabs specifically, I’d treat “conversational” as a writing choice, not a recording style: TTS loves a tight script with short sentences, light contractions, and breathing room between ideas. Fully off-the-cuff usually reads mushy once it’s synthesized.

What I do is write it exactly how I’d explain it to another founder out loud — then edit for pacing (cuts, not fancy words). If it sounds natural when you read it aloud at the tempo you want, the voice will too.

Congrats on the launch — that’s a huge step.

If you want one practical “first video” tip: pick one moment the app nails (the “aha”), storyboard 3–5 beats, then keep the whole thing under 30s. Hope the workflow saves you a ton of reshoots.

Nice timing on the TikTok push right after launch. Are you planning to show the product in action or more of a behind the scenes founder journey style?

You framed the deeper shift better than I did in the post.

“Cheaper” is the headline people click; compressed iteration loops with product context are what actually changes outcomes. The old model wasn’t just expensive — it was slow and brittle, because every revision bounced between people who didn’t all share the same mental model of the UI.

The stunt double is basically “remove the stochastic layer” (real apps, real data, real network timing) so you can focus on story + clarity.

On the next 12–24 months: I agree on pipelines over one-off assets — but I’d add the constraint that the moat won’t be the tools, it’ll be taste + narrative + what you choose to regenerate vs ship. Everyone gets the same factory; early teams that win are the ones who can run it weekly without shipping misleading demos.

Thanks for the thoughtful read — this is exactly the kind of conversation I was hoping the post would start.

Appreciate that — “stunt double” clicked for me once I stopped thinking of it as a shortcut and started thinking of it as risk control for anything time-based.

And you’re right on the economics: pipeline beats one-off because your UI will keep moving, and updates stop being a “project” and become a quick refresh pass. That’s the part I’m optimizing for now, not squeezing another 5% out of one render.

100% — that “same source, many surfaces” thing is the quiet upgrade.

The only caveat I’d add is you still need formats (crop, pacing, captions, sometimes simplifying density for a 9:16 clip vs a wide hero), but you’re editing from a controlled master, not re-chasing a live app every time.

Agency footage really is a snapshot; this is closer to versionable creative — which matters insanely fast once you ship weekly.

Love the “different jobs, different tools” phrasing — that’s exactly it. The real app shouldn’t have to audition.

Your timing note is huge too. I’ve found the same: timeline-shaped prompts beat “make it smooth” every time, because you’re giving Claude something testable instead of something interpretive.

On distribution: agreed — solving production just means you no longer have that excuse. The next bottleneck is boring and human: distribution, offers, positioning, consistency — the stuff that doesn’t autocomplete.

Appreciate you reading closely enough to add that prompt detail; that’s the kind of comment that upgrades the post for the next person who tries it.

That means a lot — thank you. If you only do one thing when you try it, spend the time upfront writing the scene list beat-by-beat; the recording part becomes almost boring after that. Hope your demo turns out exactly how you picture it.

Nice that you are already thinking about the demo before launch. Most founders leave that way too late. What is the product?

For me it doesn’t break — it changes shape. Multi-step flows and dense dashboards are totally doable if you treat each beat as its own scene and stitch in edit; that’s how real shoots work too. Where it gets painful is real branching logic — “if user is in state A, show B unless C.” The move there isn’t to simulate the whole product; it’s to script one golden path and have the HTML perform that story on rails. You’re not proving the engine, you’re showing the narrative most demos were always pretending anyway — you’re just being honest about it.

Yeah — I’ve had “pretty” cuts that still felt empty because the story was thin.

I script it like a shot list, not landing-page prose: each beat is one idea, ~3–7s, in order — what you should get and what you should feel — and I split what’s said from what’s on screen so they’re not fighting.

Only then do I touch the visuals. When I skip that step, I always end up “fixing it in Claude” for an hour and the real problem was the script.

I get that feeling — the gap between what the tools can do today and what most people assume they can do is still huge. Developers see it because we’re the ones turning “vague demo” into something shippable in an afternoon.

I’m less interested in convincing skeptics in the abstract than in showing a concrete workflow like this one. Proof beats rhetoric.

If you try it on something you’re building, I’d love to see what you come up with.

Exactly — people optimize the wrong layer. The hard part was never “get a clean capture”; it was controlling what’s on screen. HTML gives you that control without fighting your real app.

And yeah: cheaper is the boring headline. Repeatable is what actually changes how you work — same pipeline, new scenes, refreshed when the product moves.

Distribution is the bottleneck I’m staring at too. At least it’s the right one to have once production isn’t eating the calendar.

Thanks for reading — curious what you’re building?

Glad the stunt double framing landed — it felt obvious once I named it too, which is usually the sign of a real insight.

The honest distribution note was deliberate. The "10k views overnight" posts are real but they're survivorship bias dressed as a tutorial. The workflow is solved. The audience problem isn't.

No direct conversion data to compare against since I didn't run an agency video first. But the signal I'm watching is whether someone who lands on the page starts a trial, and the videos haven't moved that number meaningfully yet.

Your framing is right though — at MVP stage the video isn't for conversion, it's for clarity. Does the viewer understand what the product does in 30 seconds? That's the only question worth optimizing for early on.

What are you building?

The time cost reframe is the honest version of this post and you're right to name it. $0 in tools but 11 hours of your own work at a self-billed rate isn't free — it's just a different budget line.

The 80/20 split on agency output is where I'd push back slightly. The 20% agencies keep isn't just polish — it's creative direction and the judgment about which story is worth telling. That part doesn't compress with better tools. It just becomes more exposed when production quality is no longer the differentiator.

Re-paste the relevant component files at the start of each new video conversation — Claude picks up whatever changed automatically. For cursor movement, script hesitation not smoothness: add micro-pauses before clicks and a slight overshoot. Pure linear motion reads as puppet. Small imperfection reads as human.

The art direction point is the one most people will miss and then blame the tool for. Claude can execute a scene precisely — it can't tell you which scene is worth making.

The founders who struggle will have great prompts and no story.

Scene descriptions first, then component specs. Starting with "what should the viewer see and feel" before "how should it be built" keeps Claude oriented toward the output rather than the implementation. The skeleton I'm building now has a scene template at the top, design tokens in the middle, and a "do not include" list at the bottom for things that looked wrong in previous iterations.
25 minutes by demo five is the target I'm working toward.

"Reprompt instead of reshoot" is the line I'm most glad landed. The mental model shift from video-as-asset to video-as-living-file is what makes the whole workflow worth the setup cost.

The gatekeeping point is fair and intentional. The tools aren't the secret — the workflow is, and workflows only improve when more people stress-test them. Curious what you build with it.

Appreciate that. The pace of change genuinely is remarkable — the tools that exist now vs three years ago are almost unrecognizable. Good luck with whatever you're building too.

You're right that distribution matters more than production quality at early stage. The workflow solves the wrong bottleneck for most founders — production was never really the problem.

On diminishing returns: yes, and it hits earlier than most people expect. "Good enough to not embarrass you" is a real threshold and it's lower than it feels. Beyond that point, another hour on the video does less than another hour finding the right subreddit or writing one honest IH post.

The honest version of this article is probably: production cost is no longer an excuse, but it was never really the excuse anyway.

What's your product?

he caption correction pass is a real step I should have included. CapCut's accuracy on plain English is genuinely good. Anything product-specific — feature names, technical terms, your own brand name — gets mangled with confidence. I do a read-through before export on every video. The other one to watch is pacing: auto-captions sometimes chunk phrases in ways that read awkwardly on screen even when the audio is fine. Splitting them manually takes three minutes but makes a visible difference. Good addition — adding both to the workflow notes.

Honest answer: it degrades with complexity but more gracefully than I expected. Multi-step flows work if you break them into scenes and prompt each one separately, then stitch in CapCut. Where it struggles is genuinely conditional UI — states that depend on each other in ways that require real logic. The workaround is to fake the condition: script exactly what fires and when, and Claude builds that specific path rather than the full decision tree. You're not demoing a system, you're demoing a story. Most product demos are doing that anyway, they just don't admit it.

Distribution is still the bottleneck. But at least now it's the right bottleneck to have.

Nice — how’d the first pass go?

yep ;)

Thanks — $5,000 to $0 is the number that lands but the real unlock is the workflow behind it.

And it never has a bad take. Every frame is exactly what you scripted. The real product has opinions about timing. The HTML version doesn't.