Demo as code: Turn a recording into repo owned demos

On a previous project, I built a demo for a Series A pitch using a screen-recording tool. It looked clean. Three weeks later, I opened it before a follow-up call and realized the dashboard I'd recorded no longer existed. We'd shipped a full redesign in between. The recording was stuck in a vendor's cloud, locked away, and the only fix was to re-record every screen. I did it. It ate most of an afternoon I didn't have.

That's when demo as code clicked for me. The demo should live in the repo, next to the product, so it can be versioned, edited, and maintained by an agent. Not trapped in someone else's SaaS. This guide walks through the workflow.

What demo as code actually means

The artifact lives next to the product

A code-owned demo is a file, or a small set of files, that lives in your repo the same way a component or a config does. You can open it in your editor, diff it in git, and update it with a prompt. It is not a recording hosted on someone else's servers. It is not a presentation locked behind a vendor's export button.

The format is usually HTML with embedded styles, a few JSON fixtures for demo data, and a simple navigation layer that handles the click-through flow. The whole thing fits in a `/demo` folder next to `/src`.

Why ownership changes the workflow

When the demo is code you own, your editor is where the fix happens. Not a vendor dashboard. Not a re-record session. You open the file, change the label, commit, done. If you're using Cursor or Claude Code, you re-prompt and review the diff.

The difference is pretty simple: a hosted recording gives you a URL to share. A repo-owned demo gives you a URL to share and a file to maintain. That second part changes the economics of every later update.

Inkly's docs describe this as the Mintlify-for-demos model: their platform, your code. The demo ships from their CDN, but the source lives in your repo and any agent can touch it.

Start from the recording you already have

Capture the flow before you rewrite it

You probably already have a Loom, a screen recording, or a walkthrough video from a previous demo call. Don't throw it away. That recording is your source of truth for what the demo should show, which screens matter, which interactions tell the story, and where the flow starts and ends.

Watch it once with a text file open. You're not transcribing dialogue. You're logging screens and actions: "lands on dashboard → clicks New Project → fills in name → sees confirmation modal → lands on project detail." That list is your demo script.

Pull the steps out of the video

Each screen transition in the recording maps to one step in the demo code. A step is a screenshot or HTML snapshot of that screen state, a highlight or annotation if needed, and a click target that advances to the next step.

The recording becomes a structured list of `(screen, action, next-screen)` tuples. That's the input the agent needs. You're turning a passive video into an editable script, which is really the difference between a movie and a screenplay.

PostHog's guide on giving S-tier demos makes the same point from the delivery side: the demo that lands is the one where every step is deliberate, not the one where every screen gets shown. Use the recording to find those deliberate steps and cut the rest.

What to keep and what to throw away

Keep the entry point, the two or three moments where the product's value is obvious, and the exit CTA. Cut loading states, navigation that doesn't advance the story, and any screen that only exists because you happened to click through it during the recording. A five-minute recording usually contains a ninety-second demo.

Use Claude Code or Cursor to author the demo flow

Write the prompt like a build ticket

Don't prompt the agent with "make me a demo." Prompt it like a ticket:

"Build a three-screen interactive HTML demo. Screen 1: dashboard with a 'New Project' button. Screen 2: a modal with a name field and a Create button. Screen 3: the project detail view with a success banner. Each screen should be a self-contained HTML state. Navigation via click on the highlighted element. Output as `/demo/index.html` with inline styles."

That prompt gives the agent something it can actually write. The agent is generating the first draft of a real artifact, so treat it like a PR from a junior engineer. Review it before it ships.

Vercel's blog on rethinking prototyping at Code and Theory covers a similar pattern: agent-generated code as a starting point that a human reviews and refines, not a finished product you deploy blind.

Review the generated code before you trust it

Check three things: does the navigation flow match your script, does the copy match the current product, and do the click targets work on mobile if the demo will be viewed on a phone. The agent will usually get the structure right and sometimes hallucinate a label or miss a breakpoint. That's a two-minute fix in your editor, not a re-record.

Where the editor fits in the loop

After the agent's first pass, you're in your IDE doing a normal code review. This is the part no hosted demo tool can replicate: you can search the file, refactor a component, or ask the agent to change every instance of a label in one prompt. The editor is not an afterthought. It's where the demo becomes maintainable.

Set up a repo structure that stays readable

Keep the demo flow, assets, and variants separate

A clean layout for the demo workflow in your repo:

The base demo is the thing you maintain. Variants branch from it and inherit the flow while overriding the branding, copy, or sandbox data. When the base changes, variants get a targeted update, not a full rebuild.

Use git history as the change log

Every demo update is a commit. That means you have a record of what changed, when, and why. When a prospect asks "is this showing the current product?" you can answer with a SHA instead of a guess. Branches let you keep a stable investor-pitch version while the sales demo keeps moving on main.

This is the part screenshot-based tools can't give you. There's no diff view for a Supademo recording. There's no branch. There's just the current recording and the previous one, and you have to remember which is which.

Update demo as code when the UI changes

The before-and-after of one UI change

Say you ship a nav rename: "Projects" becomes "Workspaces." In a hosted recording tool, you open the editor, find every screen where the old label appears, and re-capture or manually patch each one. If the nav is on eight screens, that's eight passes.

In a repo-owned demo, you open `index.html`, run a find-replace on "Projects" → "Workspaces," and commit. Or you re-prompt the agent: "Update all nav references from Projects to Workspaces." Done in under two minutes, and the diff is in git.

Keep the change local

The payoff of code-owned demos is that a small UI change stays a small change. You edit one file, in one place, with your normal tooling. The change doesn't ripple into a re-capture job or a support ticket to a vendor.

What breaks first in vendor-locked tools

The failure mode is predictable: a UI change ships on Friday, the demo still shows the old UI on Monday, and you find out on a live call. The recording is immutable. It shows exactly what you captured, which is no longer what the product looks like. The only fix is re-recording, which is a time-blocked task, not a quick edit.

Code-owned demos don't have that failure mode because the artifact is editable. The demo can change the same day the product does.

Ship a quick validation pass before the live call

Run the demo flow like a check, not a performance

Before any live call, open the demo and click through every step. You're checking whether all navigation targets work, whether the copy matches the current product, and whether the final screen lands on the right CTA. This takes three minutes. It catches the thing that would have cost you the call.

Catch the broken step before your prospect does

The step that breaks first is usually the one that depends on a specific label, route, or data fixture that changed since the last time you touched the demo. A nav rename, a route change, a placeholder that now shows production data instead of sandbox data. One click-through catches all three.

Keep a short checklist in the repo, a `DEMO_CHECK.md` with five lines: entry point loads, navigation advances, copy is current, CTA is correct, mobile view works. Run it before every call. It's not really a QA process. It's a two-minute habit.

Where Inkly comes in

The workflow above, recording to script to agent-generated code to repo, is exactly what Inkly is built around. The problem here is real: a demo locked in a vendor's SaaS is a recording you can share but can't maintain. Every UI change, every new customer, every variant turns into a re-record job instead of a targeted edit.

Inkly makes the demo code you own. You capture with the Chrome extension, about as fast as Supademo for the first demo, and the output is HTML you can put in your repo and maintain with your coding agent. When the product ships a change, you re-prompt instead of re-recording. When a new customer wants their logo and data in the demo, you re-prompt for a variant off the same base code. No new recording. No manual click-by-click patch.

The honest tradeoff is the MVP path: bring your own agent, whether that's Cursor, Claude Code, or Codex. If you don't have one of those set up, there's some onboarding cost. If you do, the loop is prompt to create, update, and produce variants, and the demo moves with the product instead of falling behind it.

FAQ

Q: What does 'demo as code' actually mean in a modern AI-assisted workflow?

The demo is an HTML file, or a small set of files, that lives in your repo and is versioned like any other artifact. An AI coding agent, whether that's Cursor, Claude Code, or Codex, authors and maintains it from prompts. The ownership model does not change because AI is involved: you still own the code, it still lives next to the product, and the agent is just writing the first draft.

Q: How do I turn a recording or rough prompt into a reusable demo I own in code?

Watch the recording and log the screens and actions as a structured list: entry point, key interactions, exit CTA. Hand that list to the agent as a build ticket with specific output requirements, like file path, screen count, and navigation behavior. The agent generates the HTML; you review the diff and fix anything it got wrong. Human judgment handles the copy and product-specific behavior; generated code handles the structure.

Q: What is the fastest path to build a demo with Claude Code, Cursor, or another coding agent?

Capture the flow with a Chrome extension or use an existing recording to extract the step list, then write a tight prompt that specifies the output file, the screen states, and the navigation behavior. The agent writes `demo/index.html` in one pass. You review, commit, and the demo is live. No platform export step, no round trip through a vendor UI.

Q: How do I keep demo code maintainable when the product changes every sprint?

Separate the base demo from variants in the repo, and treat every demo update as a commit with a meaningful message. When the product ships a UI change, update the base demo with a targeted edit or a re-prompt. Don't touch the variants unless the change affects them. Git history becomes the change log, so you always know which version ships where.

Q: What folder structure, file format, or repo pattern should I use for demo assets?

Keep a `/demo` folder at the repo root with three subdirectories: `/base` for the canonical flow, with an `index.html` and a `flow.json` step definition; `/assets` for screenshots and placeholder data; and `/variants` for per-customer or per-use-case branches. Each variant folder overrides branding and copy but inherits the base flow. Flat, readable, and easy for any agent to navigate.

Conclusion

The demo that lives in a vendor's SaaS is a recording you share once and scramble to update forever. The demo that lives in your repo is an artifact you own, maintain with a prompt, and branch for any customer without re-recording anything.

Convert one existing recording into `/demo/index.html` this week. Use your recording to extract the step list, hand it to Claude Code or Cursor as a build ticket, review the output, and commit. Then run the five-line validation check before your next live call. That's the whole workflow, and once it's in the repo, every later update is a prompt, not an afternoon.