How to record an interactive demo in your repo
Learn how to record an interactive demo as code in your repo, then update it with Cursor, Claude Code, or Codex instead of re-recording every change.
Interactive demos usually fall into two buckets, though most guides blur the line: recordings trapped inside a SaaS platform, and demos that are just code you own. If you want to record an interactive demo without piling up maintenance debt, start in your repo, not in a separate tool. The big difference is not speed. Both paths can get you a shareable demo pretty quickly. The real difference shows up the moment your product changes.
Why ownership is the real test for an interactive demo
The fork in the road: recording versus owning
A tool-owned recording captures your UI, stores it in the vendor's cloud, and gives you a link. That part is easy. The problem starts when you ship a nav change, rename a CTA, or add a step to the flow. Then you're back in the editor, re-recording the screens that broke.
A code-owned demo works differently. The capture produces files. Those files live in your repo next to the product code. Updating the demo is a diff, not a re-record.
The workflow that stays sane over time is the second one. Not because capture-first tools are bad, but because they are genuinely fast for a first draft. Once the product ships, the demo that lives as code is the one you can actually keep up to date.
What changes when the demo lives next to the code
When the demo is in your repo, it moves with the product. You version it the same way you version everything else. You can branch it for a new customer the same way you branch a feature. A pull request for a label change in the demo looks a lot like a pull request for a label change in the app.
PostHog's session recording config is a useful reference here. It is a product-behavior artifact that lives in code, gets versioned, and gets reviewed like any other file. That's the model. Your demo can work the same way.
---
Choose the lightest capture method that fits your product
Browser extension, desktop app, HTML capture, or screenshots
Four methods, four tradeoffs:
- Browser extension — the fastest path to a first demo. Click through your flow and the extension captures it. Works for most web products. The output is screenshots or an HTML clone, depending on the tool.
- Desktop app — useful when the product isn't web-based or when you need to capture OS-level UI. Slower to set up, broader coverage.
- HTML capture — records the live DOM, not just pixels. The demo stays interactive and editable as code. This is the method that gives you a maintainable artifact, but most interactive demo tools hide it behind a paid tier. Supademo gates HTML to Growth ($350–450/mo), Arcade moved HTML to Enterprise-only, Storylane gates it to Growth ($500–625/mo). If you want HTML capture without the paywall, that matters.
- Screenshots — the simplest output. Fast, but every captured screen is static. A button label change means re-capturing that screen.
For a maintainable interactive demo workflow, HTML capture is the default I would pick when the UI itself matters and you want to edit the result later.
When mobile and Figma need a different path
Mobile flows do not capture cleanly through a browser extension. If the demo needs to show a native mobile UI, record it as video first, then use that as the reference for a coded demo. Do not force it through a browser capture tool.
Figma is the better shortcut when the product does not exist yet or when the demo needs to show a future state. Figma prototypes are interactive enough for early investor demos. Move to a code-owned demo once the live product is stable enough to capture.
What to skip if you just want the fastest honest draft
Skip desktop recording tools if the product is web-based. Skip full video walkthroughs. They are not interactive and they go stale faster than anything else. Skip any tool that makes you book a sales call just to unlock HTML capture.
---
Record the first version with a flow that matches how your product works
Start from the user path, not the feature list
Map the demo path before you open any capture tool. One job. One outcome. One flow. If the demo tries to show everything the product can do, it will sprawl into a product tour nobody finishes.
Write the steps as a numbered list first: what does the user click, what do they see, where does the flow end? If the list has more than seven steps, cut it. The demo is not documentation.
Make the first draft short enough to survive review
A practical setup before you hit record:
- Clear browser state, close tabs, log out of unrelated accounts, and reset any demo data
- Set the window to a consistent size
- Walk the flow once without capturing to catch broken steps
- Record only the moments the buyer needs to see, and skip loading states, settings screens, and anything that does not move the story forward
- End on a clear CTA, not on a dashboard
Stripe's analysis of how SaaS platforms ship products is a useful frame here. The pattern that works is shipping the smallest thing that proves the promise, then iterating. The same logic applies to a demo.
Use HTML capture when the UI itself is the point
If the demo needs to stay close to the live interface and be editable later, HTML capture is the cleaner first draft. The output is code. You can change a label without re-capturing the screen. You can hand it to an agent and say "update this step to match the new nav," and the agent has something useful to work with.
---
Move the demo into your repo so it can be edited like code
Turn the recording into files your team can version
After capture, the demo should be a folder of files, not a link to a SaaS editor. HTML, assets, config. Check those files into the repo. Put them next to the product code, not in a separate repo and not in a shared drive.
Once the demo is in version control, maintenance turns into normal engineering work. `git diff` shows what changed. A PR review catches a broken step before it ships. The demo gets a commit history.
Use Cursor, Claude Code, or Codex for the first rewrite
The prompt-to-diff loop looks like this:
- Open the demo files in your agent
- Describe the change: "The nav item 'Settings' was renamed to 'Preferences' — update every step that references it"
- Review the diff the agent produces
- Commit it like any other code change
No re-record. No clicking through the capture tool again. The agent edits the code; you review the diff. That's the whole update workflow for a code-native demo.
What a real UI change looks like in the repo
Say the product ships a route change, and `/dashboard` becomes `/home`. On a screenshot-based tool, every screen that shows the URL bar needs to be re-captured. On an HTML-captured, repo-owned demo, the agent finds every reference to `/dashboard` in the demo code and replaces it. One prompt, one diff, one commit.
---
Branch demos for different audiences without starting over
One base demo, several routes
Keep one source demo in the repo. When a new customer needs a tailored version, with their logo, their company name in the sandbox data, or their use case in the CTA, branch it. The branch inherits the full flow. You change only what is different.
This is basically the interactive demo version of a feature branch: the main demo is the trunk, and per-customer variants are short-lived branches that get merged or archived after the pitch.
When a branch beats a brand-new recording
Branch when the flow is the same and the surface details change: different logo, different CTA copy, different proof point in the sidebar. Do not branch when the product surface is actually different. A demo for a mobile use case that needs a completely different flow is a new demo, not a branch.
The persona split that actually matters
Before creating a branch, ask what changed for this viewer: their job, the product surface they care about, or the proof they need to see? If only the branding changed, that is a prompt. If the flow itself needs to change, that is a branch. If the product surface is genuinely different, start a new base demo.
---
Test the interactive demo before you publish it
Run the product-flow check, not a vibes check
Open the live product and the demo side by side. Click through both. Check every label, every button state, every transition. The question is not "does this look good?" It is "does every step in this demo match what the product actually does right now?"
The one publish check that catches most mistakes
Before publishing, walk the demo on the current branch of the product, not on main from last week. If the product shipped anything since the last demo update, assume something changed. One pass through the flow, comparing the demo to the live UI, catches most stale steps before a viewer sees them.
---
Where Inkly comes in
The structural problem here is the same one you run into with every platform-locked demo tool: the demo is an artifact inside someone else's SaaS, so every product change sends you back to their editor. That is not a feature gap. It is the architecture they chose.
Inkly is built on the opposite premise. The demo is code you own: HTML files, in your repo, next to your product. Capture starts with a Chrome extension, so the first-demo experience is still quick, like Supademo, but the output is code, not a recording in a vendor's cloud. When the product ships a change, you re-prompt your agent (Cursor, Claude, Codex) against the existing demo code. No re-record. When a new customer needs a tailored variant, you prompt for a branch, with the same flow, new branding, and new sandbox data. HTML capture is available on the free tier, with no paywall.
The tradeoff is simple: Inkly's MVP requires a coding agent (Cursor, Claude, Codex). If you do not already have one in your workflow, the bring-your-own-agent path adds setup that Supademo's all-in-platform flow skips. But if you already work in a repo with an agent, the demo becomes code you own and maintain like any other file, not a recording you have to redo every time the product moves.
---
FAQ
Q: What is the simplest way to record an interactive demo without creating maintenance debt?
Use HTML capture and move the output into your repo. A demo that lives as code next to your product can be updated with an agent prompt when the UI changes, so you do not have to re-record or click through the capture tool again. The simplest path that avoids debt is the one that produces an editable file, not a platform-locked recording.
Q: Should I use a browser extension, desktop app, HTML capture, screenshots, or a code-native workflow?
For most web products: browser extension for speed, HTML capture for maintainability. Screenshots are fast but require re-capturing every changed screen. Desktop apps cover non-web UI but add setup. If your goal is a demo you can keep current as the product ships, HTML capture into a code-native workflow is the right combination. The extension gets you the first draft fast, and the code output turns every later update into a diff instead of a re-record.
Q: How do I turn a prompt or product flow into an interactive demo that I can keep iterating on?
Map the user path first: one job, one outcome, seven steps or fewer. Capture it with HTML capture so the output is code. Check those files into your repo. From there, every update is a prompt to your coding agent: describe the change, review the diff, commit it. The demo iterates the same way the product does.
Q: What should I plan before I start recording so the demo stays short and focused?
Write the steps as a numbered list before you open any capture tool. If the list goes past seven steps, cut it. Clear browser state, set a consistent window size, and walk the flow once without capturing to catch broken steps. Record only the moments that move the buyer's story forward. Skip loading states, settings screens, and anything that does not directly prove the promise.
Q: How do I edit or personalize a demo after capturing it?
In a code-owned workflow: open the demo files in your agent, describe the change, review the diff, commit. For per-customer personalization, branch the base demo and prompt for a variant, like a new logo, new CTA copy, or new sandbox data, off the same base code. In a platform-locked workflow, you are back in the vendor's editor clicking through each affected screen manually. The difference is whether the demo is a file your agent can read, or a recording only the vendor's UI can change.
---
Conclusion
The choice is simple once you name it: a demo that lives in your repo is a file you can edit; a demo that lives in a vendor's SaaS is a recording you re-do. Record the first version with HTML capture, move the output into source control, and treat every later update as a prompt to your agent rather than a trip back to the capture tool. Pick one flow, record it this week, and check it in before the product ships again.
Ship your next demo before the meeting starts
Interactive demos built from your real product and kept current as you ship, done for you.
