How to create a product demo from your repo

Product demos usually fall into two buckets: demos that live inside someone else's SaaS, and demos that live in your repo as code you own. This guide is about the second one, the kind your agent can build, update, and recreate for any customer without you re-recording the whole thing.

Why how to create a product demo starts with ownership

The demo is either code you own or someone else's artifact

A lot of product demo creation starts with a capture tool. You record the flow, the tool hosts it, and you send out a link. That works until the product changes. Then the demo is out of date, and fixing it means going back into the vendor's editor, re-recording the parts that changed, and publishing again. The asset lives in their SaaS, not yours.

A repo-native demo works differently. The demo is HTML and copy in a folder next to your product code. Your coding agent can read it, edit it, and generate a new version from a prompt. Setup takes a little longer. After that, updates are much easier.

What breaks when the product ships and the demo does not

The failure is straightforward. You rename the nav item from "Projects" to "Workspaces." The recording still says "Projects." You change the pricing CTA from "Start free" to "Get started." The recording still says "Start free." A prospect clicks through and sees a product that no longer matches what they just read on your landing page.

That is an ownership problem. The demo and the product live in different places, follow different workflows, and drift apart every time you ship. The PostHog guide on giving S-tier demos puts it plainly: pick one main point you want people to remember and make the demo revolve around that. That is hard to keep up when the demo is a frozen artifact you cannot easily edit.

Choose the product demo format that fits the job

When screen recording is enough

Screen recording wins on speed when the product is stable and the demo is one-off. A launch video, a walkthrough for a blog post, a quick explainer for a static feature — those are all perfectly good recording jobs. The limit is obvious: once the product ships a UI change, the recording shows old UI. If that happens once a quarter, the cost is manageable. If it happens every week, the recording becomes a burden.

When an interactive product demo earns its keep

Interactive product demo formats are worth it when the buyer needs to click, when you want to reuse the same flow across sales calls and onboarding, or when the CTA at the end has to do real work. A clickable demo lets a prospect move at their own pace, skip to what matters to them, and reach a signup or book-a-call button without a rep on the line. Vercel's write-up on designing their virtual product tour is a useful reference for how a team thinks through that decision at the funnel level.

How to avoid overbuilding the first version

Strip the demo down to the smallest version that can still convert: one use case, one path through the product, one CTA, one audience. A repo-native workflow can make it tempting to build a full demo site with branching paths and custom data for every persona. Resist that. Ship the shortest version that answers the buyer's main question and ends on a clear next step. You can add scenes later, and with a repo-native demo, adding a scene is a prompt, not a rebuild.

Set up the demo files inside your codebase

A demo folder structure that a human can read later

A repo-native demo needs a folder that a collaborator, or your future self, can navigate without context. A structure that works:

That is it. Four files, one folder, sitting next to the product code. No separate repo, no vendor dashboard, no login required to see what the demo says.

What belongs in scenes, script, CTA, and notes

• scenes.html — the interactive flow: screen order, UI state, click targets, transitions.
• script.md — the copy: what each screen says, headlines, microcopy, value statements.
• cta.md — the conversion point: the button, the destination URL, the ask.
• notes.md — change history: what changed, when, and why, so the next update has context.

Each file has one job. When the product ships a change, you open the relevant file, re-prompt the agent against it, and commit. The Zapier / v0 case study on Vercel shows how removing per-prototype design work compounds over time. The same thing applies to demo maintenance when the demo is code you can re-author.

Use AI to create the first product demo draft

Prompt the agent for structure before polish

An AI-assisted demo workflow starts with structure, not wording. The first prompt asks the agent to draft the scene order and the CTA before touching copy. Something like: "Draft a five-screen interactive demo for [product name]. The buyer is a [role]. The main job-to-be-done is [task]. Scene 1 shows the problem. Scenes 2–4 show the product solving it. Scene 5 ends on [CTA]." The agent fills in the structure. You edit the structure. Then you prompt for copy.

This order matters. If you prompt for copy first, you get polished words on top of a weak flow. It is faster to fix the flow at the structural stage than after the copy is already written.

Cursor, Claude Code, and Codex each fit a different setup

• Cursor — best when the demo lives in the same repo as the product. Cursor reads the surrounding code, so it can pull actual UI copy, route names, and component labels directly into the demo without you spelling them out.
• Claude Code — best for iterative prompt-and-review loops. Strong at generating and revising `scenes.html` from a description, and at producing per-customer variants from a base file.
• Codex — best when the demo is part of a CI workflow or when you want to automate variant generation at scale.

All three can read `scenes.html`, `script.md`, and `cta.md` and produce a revised version from a plain-language prompt. The demo being code is what makes that possible. A recording locked in a vendor UI cannot be re-authored by an agent.

Write the script, scenes, and CTA for a short product demo

The script should move from problem to proof to action

A short product demo script has three beats: show the problem the buyer recognizes, show the product doing the job, end on the CTA. No feature tour. No "and here you can also..." detours. The buyer should finish the demo knowing one thing: this product does the job I need done, and here is how to get it.

Keep the script in `script.md` as plain copy, one line per screen. The agent can revise it in place when the messaging changes, so you do not have to re-record anything or open an editor.

Scenes should show one job, not the whole product

Pick one use case. Walk one path through the product. The buyer watching the demo should be able to picture themselves doing that exact thing. A demo that tries to show five use cases shows none of them well, because the product keeps shifting.

If you have multiple audiences, build a base set of scenes and produce a variant per audience from a prompt. Same structure, different copy and data. That is what the `notes.md` file is for: tracking which variant is which and what changed between them.

The CTA should match the audience, not the asset

A launch demo CTA asks for signup. A sales demo CTA asks for a call. An onboarding demo CTA asks for activation of a specific feature. The CTA in `cta.md` should match the next step the audience actually wants to take, not a generic "Get started" that works for nobody in particular. When the audience changes, update `cta.md` and re-prompt. One file, one prompt, done.

Update the product demo when the product changes

What changes first: the scene, the script, or the CTA?

When the product ships, check in this order:

• Scenes — did any UI element the demo shows change? Nav label, button position, screen layout. If yes, update `scenes.html` and re-prompt the agent to reflect the new UI state.
• Script — did any copy on those screens change? Headlines, microcopy, value statements. If yes, update `script.md`.
• CTA — did the conversion destination or the ask change? If yes, update `cta.md`.

Most product changes touch scenes and script. The CTA changes less often. Checking in this order means you do not waste time on copy when the screen it lives on no longer exists.

Version notes are how you keep launch, sales, and onboarding separate

Different demos can share a base set of scenes but need different notes, CTAs, or copy for different jobs. Keep a short log in `notes.md`: date, what changed, which variant it affects. That log is what lets you update the sales demo without accidentally changing the onboarding demo, and it helps a new collaborator understand the state of the demo without asking you to explain it.

Know when a screen recording is still the right product demo

Static products and one-off launches do not need a repo workflow

If the product will not change, a screen recording is the lowest-cost option. A one-time launch video, a conference walkthrough, a static feature explainer — those do not need a folder in the repo. Set up the repo-native workflow when the demo has to stay aligned with a product that ships regularly.

The cheapest demo is the one you do not have to maintain

A recording is cheap to make and free to host. It gets expensive the moment the product changes and the recording shows old UI. If your release cadence is monthly or slower, a recording may cost less over time than a repo-native setup. If you ship every week, the re-record cost adds up quickly, and the repo-native workflow pays for its setup cost within the first few updates.

Where Inkly comes in

The structural problem this article is built around is simple: most demo tools make the demo an artifact inside their SaaS. When the product changes, you go back into their editor. When a new customer wants a tailored version, you rebuild it there. The demo is never yours to re-author. It is theirs to host.

Inkly is built on the opposite premise. The demo is code you own: HTML, copy, and CTA files that live in your repo and can be re-authored by your coding agent (Cursor, Claude Code, or Codex) from a plain-language prompt. The three-prompt loop — create, update, produce a variant — replaces the three things that usually make demos expensive to maintain. The tradeoff is bring-your-own-agent: the MVP requires Cursor, Claude, or Codex already set up in your workflow. If you have that, re-prompting to refresh the demo after a product change costs one prompt instead of a re-record pass through every affected screen.

FAQ

Q: What is the fastest practical way to create a product demo that a founder or PMM can ship this week?

Pick a screen recording if the product is stable and the demo is one-off. That is the fastest way to get something shareable. If the product ships regularly, set up a four-file demo folder in the repo and use a coding agent to draft the first version from a structural prompt. The first pass takes longer than a recording; every update after that is faster.

Q: How do you create a demo that stays aligned with the actual product as features change?

Keep the demo as code in your repo: scenes, script, CTA, and version notes in separate files. When the product ships a change, check which files are affected and re-prompt the agent against them. The demo updates in the same workflow as the product, not in a separate vendor editor.

Q: What should the script, scenes, and CTA be for a short product demo that converts?

Script: problem, product doing the job, CTA. Scenes: one use case, one path, no detours. CTA: matched to the audience's actual next step, signup for a launch demo, book a call for a sales demo, activate a feature for onboarding. Keep each in its own file so you can update them independently.

Q: How can product engineers build a demo directly from the codebase or product environment?

Set up a `/demo` folder in the repo with `scenes.html`, `script.md`, `cta.md`, and `notes.md`. Point Cursor or Claude Code at the folder and prompt it to draft the demo using the product's actual route names, UI copy, and component labels from the surrounding code. The agent reads the codebase and produces a demo that reflects the real product state.

Q: How do AI-native tools like Cursor, Claude Code, or Codex fit into demo creation?

They author and maintain the demo code. Cursor is strongest when the demo lives in the same repo as the product because it can pull real UI copy and route names directly. Claude Code handles iterative prompt-and-review loops well. Codex fits automated variant generation. All three work the same way: read the demo files, revise from a plain-language prompt, commit the result.

Q: What is the simplest reusable workflow for updating and reusing a demo across launches, sales, and onboarding?

One base set of scenes in `scenes.html`, separate `cta.md` and `script.md` files per audience, and a `notes.md` log of what changed and when. When the product ships, update the affected files and re-prompt. When a new audience needs a variant, re-prompt against the base scenes with different copy and CTA. The base never gets rebuilt. Only the audience-specific files change.

Conclusion

If the demo lives in your repo, updating it is part of shipping, not a cleanup task you put off until the next prospect call exposes the mismatch. Pick one demo this week, move it into a four-file repo structure, and update it once from an actual product change. That single update loop is the proof that the workflow holds.