Product demo examples that live in your repo

Why are your product demo examples trapped inside someone else's SaaS when the product itself lives in your repo? The better setup is simple: code-owned demo examples that sit next to the app, get versioned with it, and get updated by the same AI coding agent that ships the features.

Most guides on this topic stop at inspiration. They show nice-looking demos, talk about storytelling, and leave it there. Fine, but that does not answer the question a repo-first founder actually has: how do I build a demo that still matches the product after the next release?

This is that guide.

What makes product demo examples repo-native instead of marketing-only

The ownership test

A marketing-only demo is a recording or a SaaS-hosted artifact. It lives outside your codebase, outside your version control, and outside the reach of any tool that touches your product. When the product changes, the demo does not. Somebody has to notice the gap and fix it.

A repo-native demo is code. It lives in a folder your engineers already open, it gets committed with the feature it demonstrates, and it can be diffed, reviewed, and updated like everything else. The real fear here is not polish. It is lock-in. A demo trapped in Supademo's editor or Arcade's platform is a demo you cannot update without going back into their UI.

Why the repo changes the job

When the demo is code in your repo, the update loop gets much easier. A product engineer who ships a nav rename can update the demo in the same PR. A reviewer can catch a stale CTA in code review. An AI coding agent can re-prompt the demo after a release without anyone opening a separate tool.

PostHog's guide on giving S-tier demos makes a point that fits here: the best demos feel like the product. That only works when the demo and the product share the same source of truth.

A sample repo split that works in practice:

The `/demo` folder sits at the same level as `/app`. Engineers see it. Agents can target it. Nothing about it is hidden.

Where to store product demo examples in your codebase

The folder structure that keeps the demo visible

The failure mode with repo-native demo examples is burying them somewhere only the person who created them knows about. A `/demos` folder at the repo root, or a `/demo` subfolder inside `/app`, keeps the asset visible to everyone who opens the project.

The structure should loosely mirror the product itself. If the product has an onboarding flow and a billing flow, the demo folder should have `onboarding.html` and `billing.html`, not `demo-v3-final-FINAL.html`.

What belongs in the demo folder and what does not

Versioned with the product:

Demo HTML/component files
Fixture data and seeded states (`seed-data.json`, `demo-user.json`)
Copy files (`copy.md`) - headlines, CTA text, tooltip labels
Brand assets used in the demo (logo, color tokens)

Generated on demand, not committed:

Per-customer variant outputs
Rendered screenshots or video exports
AI voiceover audio files

That boundary matters because it keeps the demo folder small and easy to review. A reviewer looking at a PR that touches `/demo/onboarding.html` should be able to understand what changed in thirty seconds.

Generate the first product demo examples from a real flow

Start from the path buyers actually need to see

The most common mistake with interactive demo examples is starting from the feature list. Start from the moment that makes a buyer say, "I get it." For a billing tool, that might be the first invoice that appears automatically. For an onboarding tool, it might be the activation milestone.

Strip the path down to the minimum number of screens that carry that moment. Three to five screens is usually enough. A ten-screen tour teaches the viewer about the product; a four-screen demo proves the promise.

Use fixtures and seeded states instead of fake hand-waving

A believable demo does not need live data. It needs realistic data. That means data with the same shapes and constraints as the real app: real field names, plausible values, and states the app can actually reach.

Store fixture data in `demo/fixtures/seed-data.json` and reference it from the demo components. When the product's data model changes, the fixture file becomes the thing that breaks. That is exactly what you want, because it surfaces the mismatch before the demo ships.

Vercel's call summary agent template organizes its demo files in a `/demo-files` folder with realistic mock data. The same pattern applies here. Seeded states, not hand-waved placeholders.

Keep the CTA tied to the buyer's next step

The demo should end on one action. For a sales-led motion, that is "book a call." For PLG, it is "start your free trial." For onboarding, it is "complete setup." The CTA should match where the viewer is in the funnel, not where you want them to be.

Hard-code the CTA target in `copy.md` so it shows up in code review and is easy to swap per variant.

Update product demo examples with an AI coding agent

The prompt-to-change loop

When the product ships a UI change, the update loop for a repo-native demo looks like this: open the demo folder, describe the change to your agent (Cursor, Claude Code, or Codex), and let the agent revise the affected files. No re-recording. No separate SaaS editor. No hunting for the screen that changed.

A prompt like "the nav item 'Settings' is now called 'Workspace' - update the demo to match" is enough for the agent to find every reference in the demo HTML and copy files and change them. It touches `onboarding.html`, `copy.md`, and any fixture that used the old label.

What the agent should touch and what it should leave alone

Agent-safe changes:

Copy edits (labels, headlines, CTA text)
UI label updates that match a product change
Fixture data updates when the data model changes
Brand asset swaps for per-customer variants

Human review required:

Structural flow changes (adding or removing a screen)
CTA target changes (booking link, trial URL)
Any change that affects what the demo proves, the core promise

The rule of thumb is straightforward. If the change is cosmetic or copy-level, the agent can handle it. If the change affects the demo's argument, a human should confirm the flow still makes sense before it ships.

A timestamped update pass

After a product release that touches the nav, billing labels, and onboarding copy, an agent update pass might look like this:

T+0: Prompt: "Update demo to reflect the new nav structure - Settings → Workspace, Billing → Plans."
T+2 min: Agent updates `onboarding.html` (two label references), `copy.md` (three headline references), `seed-data.json` (one field name).
T+5 min: Human reviews the diff, confirms the demo flow still proves the activation moment, and merges.

The same pass on a screenshot-based tool means opening the editor, recapturing every affected screen, re-annotating, and re-testing. There is no diff to review and no version history to roll back to.

Review and test product demo examples before they ship

The trust check

Before a demo ships, four things have to be true: the UI matches the current product, the copy is accurate, the CTA works, and the flow still mirrors real product behavior. Check them in that order.

A quick review checklist:

Open the demo and the live product side by side. Count mismatches.
Read every label in the demo against the current product UI.
Click the CTA. Does it go where it should?
Walk the demo path against the real onboarding or activation flow. Does it still prove the same thing?

The failure you catch only in staging

Code-owned demo examples have one failure mode that screenshot tools do not: the demo can render correctly in local dev and break in staging if the fixture data references a field that the staging environment handles differently.

The fix is to run the demo against staging before every release, not just against local fixtures. A demo that looks fine in review and shows a broken state field to a prospect is worse than no demo.

How to keep the demo from becoming a guess

The demo drifts when nobody owns the update loop. Assign demo review to the same person who owns the release checklist. One line in the PR template - "Does this change affect the demo?" - is enough to catch most regressions before they ship.

Stripe's approach to customer-facing assets treats the customer portal as a product artifact with its own release discipline. The same mindset applies to demos: they are product artifacts, not marketing collateral, and they deserve the same review gate.

Match product demo examples to audience and release cadence

Sales, PLG, and onboarding want different cuts

One base demo can branch into three variants without rebuilding from scratch:

Sales: full flow, branded with the prospect's logo, CTA is "book a call"
PLG: shorter path, ends at the trial signup, no sales friction
Onboarding: the activation moment only, CTA is "complete setup"

The base demo lives in `/demo/flows/onboarding.html`. Each variant is a prompt away: "produce a sales variant with Acme Corp branding and a Calendly CTA." The agent generates the variant file; the base stays unchanged.

Complex SaaS needs more structure than simple products

This format is worth the setup cost when the product ships frequently and the demo needs to stay current across multiple audiences. If the product ships once a quarter and has one buyer persona, a Supademo capture is probably the right call. The maintenance overhead of a code-owned demo will not pay off.

The threshold is simple: if you've re-recorded a demo more than twice in a quarter because the product changed, the repo-native model pays for itself.

Lead qualification should shape the CTA

The demo's final CTA is a filter as much as a conversion mechanism. A CTA that says "book a 30-minute call" filters for buyers who are ready to talk to sales. A CTA that says "start free" filters for self-serve buyers. A CTA that says "see the enterprise plan" filters for buyers with budget.

Match the CTA to the buyer you want to attract, and store it in `copy.md` so it is easy to swap per variant without touching the demo logic.

Where Inkly comes in

The structural problem this article describes is that most demo tools make the demo a recording inside their platform. Every product change means going back to their editor. Every new customer means a new build pass. The demo and the product live in different places, so they drift apart by default.

The tool that solves this is one where the demo is code you own, not a SaaS artifact or a recording, but a file in your repo that your agent can read, revise, and branch. Inkly is built on that premise. The demo is HTML you own; your coding agent (Cursor, Claude, Codex) authors it from a prompt and updates it the same way. A nav rename is a prompt. A per-customer variant is a prompt. The base demo does not move; the agent does the work.

The honest tradeoff: Inkly's MVP path is bring-your-own-agent. If you're not already running Cursor or Claude Code, there is setup involved before the loop clicks. But if you're already prompting your way through the product, keeping the demo in your repo is the same workflow you're already in.

FAQ

Q: What is the best way to build product demo examples that stay aligned with the product we actually ship?

Store the demo as code in your repo, next to the product. Use fixture data that mirrors real app states and a folder structure that engineers already open. When the product changes, update the demo in the same PR, or prompt your AI coding agent to handle the revision. The demo stays aligned because it lives in the same version control loop as the product.

Q: How can we keep demo examples in the repo so engineers can update them quickly?

Put the demo in a `/demo` folder at the repo root with subfolders for flows, fixtures, and copy. Keep the files small and named after the product flows they demonstrate. Add a one-line check to your PR template: "Does this change affect the demo?" That catches most regressions before they ship. Engineers update the demo the same way they update any other file: diff, review, merge.

Q: How should an AI coding agent help author, revise, and test demo examples?

The agent is useful for three jobs: writing the initial demo from a description or captured screens, updating copy and UI labels after a product change, and generating per-customer variants from the base demo. Where the agent needs human review is structural changes - adding or removing a screen, changing the CTA target, or altering what the demo proves. Prompt for the cosmetic changes; review the structural ones yourself.

Q: How do we turn one demo into reusable variants for sales, PLG, and onboarding?

Keep one base demo that covers the core activation path. Store the audience-specific parts - CTA text, branding, flow length - in a copy file and a fixture file, not in the demo HTML itself. When you need a variant, prompt your agent: "produce a sales variant with Acme Corp branding and a Calendly CTA." The agent generates the variant file off the base; you review the diff and ship it.

Q: What should a product demo example include so it is believable without a live sales rep?

Three things: real UI, realistic seeded states, and a focused CTA that matches where the viewer is in the funnel. Keep the flow to the minimum number of screens that prove the core promise. A four-screen demo that shows one clear outcome is more believable than a ten-screen tour that shows everything.

Conclusion

The ownership question from the opener has a direct answer: the demo does not have to be trapped in someone else's SaaS. When it is code in your repo, the next product change is an update, not a rebuild. Your agent handles the revision the same way it handles any other file.

Pick one product flow this week - onboarding, billing, the first activation moment - and move it into a `/demo` folder in your repo. Wire one agent prompt to it. The second time you ship a UI change and the demo updates in the same PR, the model clicks. From there, every new customer or new variant is a prompt, not a re-record.