What is an interactive demo? Build it in your repo

On a previous project, I shipped a redesigned onboarding flow on a Wednesday. By Thursday, a colleague reviewing our investor materials pinged me to say the demo we'd embedded in the deck was still showing the old empty-state screen, the one we'd killed because it made the product look half-built. Fixing it meant finding the original recording, re-editing it, re-exporting it, and re-embedding it. Two hours for a change that took twenty minutes to ship. The artifact lived in a Loom folder, not in the repo, so it moved on its own schedule, which is to say: never.

An interactive demo is code you can keep in your repo, review in PRs, and update with the same agent that ships the product. That's the frame this article uses.

Start by treating the interactive demo as part of the product, not a marketing asset

What the reader needs to know first

An interactive demo is a guided, clickable product experience. The user moves through a real-seeming flow at their own pace, clicking buttons, filling fields, and seeing state changes. It is not a video, because the user can't interact. It is not a live call, because no salesperson is needed. It is not a sandbox trial, because there is no real data, real account, or support burden. It sits between "watch this" and "try this yourself." Stripe's embedded demo experiences are a good reference point: clickable, guided, and free of signup friction.

That definition is the easy part. The harder question is where the demo lives.

The repo-owned version changes the question

Most teams treat an interactive demo as a marketing asset: something built in a vendor's SaaS, embedded on a landing page, and handed off to a campaign doc. The problem is that a demo living in someone else's platform updates on that platform's schedule, which usually means a human has to re-record or re-edit it.

A code-native team has a better option. When the demo is code in your repo, a product change triggers the same workflow as any other change: branch, edit, PR, review, merge. One team I know keeps a `demos/` directory next to `src/`. Demo changes land in the same pull request as the feature that made them necessary. No separate campaign tool. No out-of-band rebuild.

Use a bridge that shows the cost of keeping the demo outside your repo

The mismatch that forces extra work

On a previous project, we shipped a nav restructure mid-quarter. The product moved fast. The demo did not. Three weeks later, a prospect on a call asked why the sidebar looked different in the demo from the product they'd been trialing. We had no good answer. The demo was a screenshot-based capture in an external tool, and updating it meant re-capturing every affected screen, which was most of them.

That is a workflow problem, not a moral failure. The demo was built the fast way, and the fast way comes with a maintenance bill that grows every time the product changes.

What changes when the demo is code you own

A demo locked in a vendor platform has one update path: go back into the vendor's editor, re-capture or manually adjust, and re-publish. Every product change that touches the demo's screens becomes another re-capture pass.

A code-owned demo has a different update path: re-prompt your agent against the existing demo code. The demo is HTML and component logic in your repo. Your agent — Cursor, Claude Code, Codex — can read the current product state and rewrite the demo to match. No re-recording. One prompt, reviewed in a PR, merged alongside the product change that made it necessary.

Three demo formats, three different update paths

Screenshot-based demos (Supademo, Arcade) capture screen images and layer click targets on top. When the product UI changes, every affected screen needs a fresh capture. The screenshots are the demo.

HTML/CSS demos clone the product's rendered markup. Text and some layout changes are easier to adjust inline, but structural UI changes still require re-cloning the affected flows.

Code-native demos emit the demo as actual code — components, state, copy — that lives in your repo and can be re-authored by any agent from a prompt. When the product changes, the update is a conversation with your agent, not a session in a vendor's editor.

Choose the interactive product demo format that matches your product and team

Screenshot demos for fast capture, not deep ownership

Screenshot-based tools are the fastest path to a first interactive product demo. Capture the flow in the Chrome extension, layer on tooltips and click targets, publish. For a team that ships rarely or needs a demo this week, that speed matters. So does the maintenance cost: a nav rename or a modal redesign means re-capturing every screen it touches. If your product ships weekly, that adds up fast.

Best fit: marketing-led teams, early-stage founders who need a demo before the product is stable enough to clone.

HTML and CSS demos for teams that want more edit room

HTML capture clones the rendered product: text, layout, some interactivity. Changing a button label or a pricing figure is an inline edit, not a re-capture. Structural changes, like a new sidebar or a redesigned modal, still require re-cloning the affected flows. The demo is easier to edit than a screenshot, but it still lives in a vendor's system, not in code you own.

Best fit: hybrid teams where a product marketer owns the demo but has some engineering support for structural updates.

Code-native demos for product teams already living in Cursor, Claude Code, or Codex

A repo-native demo is the right call when your team already works from the codebase and wants the demo to update the same way the app does. The demo is code. Your agent authors it, your PR process reviews it, your repo hosts it. A product engineer can update the demo in the same commit that ships the feature. No vendor editor. No re-record. No separate asset management workflow.

Best fit: engineer-led teams, founders with a coding agent already in their workflow, any team where the demo needs to stay current across a fast-moving product.

Create the first repo-native demo from a prompt, then turn it into a workflow

Prompt the demo into existence

Start with the one flow that proves the product's core value. Not a feature tour. One task, one outcome. Describe it to your agent: the starting state, the steps, the moment the value lands. The agent writes the demo as HTML and component logic. Review the output, tighten the copy, and confirm the click targets match the real product. Then pick the one action the demo needs to drive — a signup link, a booking CTA, a "request access" button — and make sure it is reachable from the final screen.

Check it in like code

Create a branch: `demo/onboarding-flow-v1`. Commit the demo code. Open a PR against `main`. Write a description that explains what the demo shows and what changed in the product that prompted it. Ask someone to review it the same way they'd review a feature PR: does the flow make sense, does the copy match the product, does the CTA land in the right place? When it passes review, merge it. The demo ships with the product, not after it.

This is the workflow that version-controlled documentation practices have normalized for technical writing. The same logic applies to demos.

Keep the first version small enough to finish

One flow. One CTA. Three to five screens. The first repo-native demo is a proof of workflow, not a full product tour. If you can't finish it in an afternoon, you've scoped it too broadly. Narrow to the single moment that makes a new viewer want to learn more, ship that, and iterate from there.

Use the interactive demo as a shared surface for marketing, engineering, and sales

Product marketing wants a proof asset they can ship without begging for a rebuild

When the demo is in the repo, product marketing can file a PR to update copy, swap a screenshot, or change the CTA without opening a ticket and waiting for engineering to find time. Launches ship with a demo that matches the product on launch day, not one that matched it three weeks ago when the last capture ran.

Engineering wants fewer one-off rebuilds

Engineers get fewer "can you update the demo" requests when the demo is code they can hand off to an agent. The update path is a prompt, not a manual re-record session. Demo changes show up in PRs alongside the product changes that caused them, so they stay reviewable, reversible, and tracked.

Sales still needs a tailored path, just not a custom rebuild every time

A sales team can branch the base demo for a specific account: swap the logo, adjust the copy, change the sandbox data, and leave the underlying flow alone. The base demo stays in `main`; the account variant lives in a branch or a separate file. One agent prompt produces the variant. The core artifact stays maintainable.

The handoff model that works: PMM owns the base demo and approves copy changes; engineering reviews structural changes in PRs; sales branches for account variants and keeps them out of `main`.

Measure the interactive demo by behavior that matters, not just clicks

Clicks are not the whole story

Click-through rate tells you the demo got attention. It does not tell you whether the viewer reached the moment that proves value, or the CTA that moves them to the next step. A demo with a high click-through rate and a low CTA conversion rate has an engagement problem somewhere in the flow.

Track the action that proves intent

Anchor your analytics to one event: did the viewer reach the CTA screen and click it? Completion rate and CTA clicks are the two numbers that actually tell you whether the demo is doing its job. If you're running personalized variants for different audiences, segment by variant. A demo tailored to one persona should convert that persona better than the generic version. If it doesn't, the personalization isn't working.

Keep performance and accessibility from turning the demo into a tax

A demo embedded on a landing page adds load weight. Keep the initial load under two seconds, and lazy-load screens the viewer hasn't reached yet. Every interactive element needs a keyboard-accessible equivalent, and screen readers should be able to navigate the flow. Text in the demo should meet WCAG AA contrast ratios. Web Content Accessibility Guidelines are the reference point. A demo that fails accessibility excludes part of your audience and signals carelessness to the part that notices.

Where Inkly comes in

The structural problem this article describes — a demo that lives outside the repo, updated manually, drifting away from the product it's supposed to represent — is not a discipline problem. It is an architecture problem. The demo is in the wrong place.

Inkly is built on the idea that the demo should be code you own, next to your product, authored and maintained by the same agent that ships the product. The three-prompt loop is the whole workflow: prompt to create the demo from a description or a Chrome-extension capture, prompt to update it when the product changes, prompt to produce a variant for a new customer or a new pitch. No re-recording. No vendor editor. The demo lives in your repo, moves through your PR process, and updates when you tell your agent to update it.

The honest tradeoff: Inkly's MVP path is bring-your-own-agent — Cursor, Claude Code, or Codex. If you don't have a coding agent set up yet, that's a prerequisite, not a feature. But if you're already working that way, keeping your demo in the repo is one prompt away.

FAQ

Q: What is an interactive demo in plain English, and how is it different from a product video, live demo, or sandbox trial?

An interactive demo is a guided, clickable product experience the viewer navigates at their own pace. They click through screens, see state changes, and reach a CTA without needing a salesperson present or a real account. A product video is passive; the viewer watches. A live demo requires a person on the other end. A sandbox trial is the real product, which means real support cost and real friction to access. The interactive demo sits between "watch this" and "try this yourself" — guided enough to tell a story, interactive enough to feel real.

Q: When should a B2B SaaS team use an interactive demo instead of a live call or self-serve trial?

Use an interactive demo when the product needs proof before a prospect will book a call, when a live call is too expensive to run at volume, or when the trial onboarding is too long to show value in one session. The interactive demo is the right tool for top-of-funnel proof: it shows the product working without requiring the viewer to set anything up. A live call is still better for complex sales with multiple stakeholders. A trial is still better for bottoms-up PLG where hands-on usage is the conversion mechanism.

Q: Which type of interactive demo should a code-owned product team build: screenshot-based, HTML/CSS, in-app, or sandbox?

A code-owned team should build a code-native demo, one that lives in the repo and updates via agent prompt. Screenshot-based demos are fastest to start but require re-capture on every UI change. HTML/CSS demos are more editable but still live in a vendor's system. A sandbox is the real product, which means real infrastructure cost and real maintenance overhead. The repo-native option fits teams already working with a coding agent: the demo updates the same way the product does, through the same workflow.

Q: How do interactive demos help product marketing, demand gen, founders, and product engineers differently?

Product marketing gets a proof asset they can update without filing a ticket. Copy and CTA changes are PRs, not re-record sessions. Demand gen gets an embeddable, trackable asset that converts visitors who aren't ready to book a call. Founders get a pitch-ready demo that stays current across investor and customer conversations without a separate maintenance workflow. Product engineers get fewer one-off rebuild requests. Demo changes live in the same PR as the product changes that caused them.

Q: How do you build an interactive demo that stays easy to maintain as the product changes?

Put the demo in the repo. Use a code-native format that your agent can re-author from a prompt when the product changes. Review demo changes in PRs alongside the product changes that made them necessary. Keep the first version scoped to one flow and one CTA. The smaller the demo, the cheaper every subsequent update. When the product ships a change that touches the demo, re-prompt the agent against the existing demo code rather than re-recording from scratch.

Conclusion

The demo should live where the product lives. When it does, the next product change is a PR, not a rebuild, and the demo that goes out to your next investor or prospect is the one that matches what you actually shipped. Pick one flow this week, prompt the first version into existence, and check it into the repo. That's the whole starting point.