How to bring your AI demo to life in your repo

Open your last demo in one tab. Open your live product in another. Count the mismatches.

That count is the real answer to how to bring your AI demo to life. Not a better screen recorder. Not a shinier SaaS tool. A different premise: the demo lives in your repo, next to the product, and the same agent that helps you ship also helps you keep it current.

Here's the build path.

Start with the workflow buyers need to understand first

Most demos open on a dashboard. That is usually the wrong first screen. Dashboards show state, not action, and state without context just looks like noise.

The first screen is not the home screen

For an AI product, the first screen should be the moment the model does something visible: prompt in, answer out; file uploaded, result returned; query run, insight surfaced. That is where the value lives. A prettier landing screen only delays it.

PostHog's notes from the ElevenLabs hackathon make this concrete: the demos that landed in under 60 seconds opened on the action, not the setup. The teams that won led with the output the user cared about, not the UI that produced it.

Start there. Whatever your AI product does that makes a buyer say "oh, that's useful" is screen one.

Cut the story down to one job

Pick one outcome the demo has to prove. One. Not "here's everything the product can do" — that is a feature tour, not a demo.

For a document analysis tool we shipped, the opener was a user dragging a contract into the app. The proof moment was the model flagging three non-standard clauses in under five seconds. Everything else — settings, history, export — stayed out. The buyer understood the job in under a minute. That is the bar.

If you cannot name the one job your demo proves in a single sentence, the demo is not ready yet.

Choose the right demo format for the job

Not every part of your flow needs an interactive AI demo. The format should match the job.

When screenshots are enough

Screenshots work when the buyer only needs orientation: "where does this setting live?", "what does the output look like?" They are fast to produce, fast to update, and fine for documentation-adjacent contexts. They fail the moment the buyer needs to feel the flow instead of seeing a frozen frame of it.

When GIFs and video are the cheaper move

Motion assets show behavior without making the buyer click. For a feature that is hard to describe in text — a drag-and-drop interaction, a real-time typing animation — a short GIF is often the right call. The limitation is simple: the buyer watches, they do not explore. There is no live path through the product.

When code-native interactivity is worth it

An interactive AI demo earns its complexity when the buyer needs to click through a believable flow, not watch one. That matters when the demo will live on the website, get sent in sales follow-up, and stay accurate after the next product release. That is three contexts, one asset. A recorded GIF cannot do that job. Code-native interactivity can, because it is a real artifact you can update with a prompt instead of re-recording from scratch.

One real split that works: static screenshots for the settings screens, code-native interactivity for the core AI workflow. Buyers just need orientation in one place and a feel for the model response in the other. As Vercel's AI agent build guide shows, separating "show state" from "show behavior" is the right move for agent-driven products.

Build the AI demo as code you own in your repo

This is the structural move. A code-native demo, living next to the product, makes the rest of the maintenance loop possible.

Give the demo its own folder, not its own universe

The structure is simple. Inside the repo:

The demo lives beside the product. When the product changes, the demo patch happens in the same branch. No context switch to a separate SaaS, no re-recording in someone else's UI.

Let your agent author the boring parts

The prompt-to-create loop with Cursor, Claude, or Codex is straightforward: describe the demo flow in `prompts.md`, point the agent at your product's actual UI, and let it write the demo shell. The agent produces the HTML structure, wires up the scripted states, and stubs the copy. You tighten the flow, remove anything that does not serve the one job, and commit.

The human's job is judgment, not production. The agent handles the repetitive parts.

Keep the demo assets close to the code that uses them

Every asset the demo needs — screenshots, short clips, voiceover files, translated copy — lives in `/demo/assets`. When a UI change forces a screenshot update, the updated file and the flow code that references it sit in the same directory. That proximity is what makes updates fast: you change the asset, re-prompt the agent to update any references, and the demo is current.

A real file pair that changed together on one release: `assets/result-panel-v2.png` and `flow/step-3.html`. The result panel UI changed, the screenshot updated, and the agent rewrote the step-3 wrapper to match the new layout. Two files, one commit, done.

Make the demo believable when AI output changes

AI output is variable. A demo that pretends otherwise falls apart the first time a buyer pushes it.

Use guardrails where the model gets slippery

Find the parts of the flow where the model's output could vary in ways that break the story. Those parts get fixed text or simulated states, not live model calls. The parts that are stable and impressive stay live.

For a summarization product, the model's one-line summary was the proof moment, but the exact wording varied run to run. The fix was a scripted fixture with a representative output, labeled "example result." Buyers understood it was illustrative. The demo still landed.

Script the moments buyers will question

One release changed the model's confidence scoring. What had been a percentage became a qualitative label ("high / medium / low"). The demo showed the old format for two days before we caught it. The patch was a one-line fixture update. The lesson was simple: script any output that buyers will scrutinize, and put it in `/demo/states` so it is obvious when the product's behavior drifts from what the demo shows.

Use narration to explain the gap, not cover it up

If the demo shows a simulated result, say so. A short line of on-screen text — "Example output — your results will vary by input" — is more credible than a demo that implies live model calls it is not making. Buyers who catch an unexplained gap lose trust fast. Buyers who see an honest label stay engaged.

Stripe's lessons from building agentic products make the same point about agent-facing demos: surface the constraints, do not hide them. Buyers who understand the model's behavior trust the product more, not less.

Ship one demo across the website, sales follow-up, and launch pages

Build the opener, proof, and CTA once

The core flow has three parts: opener, proof, CTA. Build those once. What changes per channel is minimal:

• Website: the CTA is "try it" or "sign up." The proof moment runs without narration.
• Sales follow-up: the opener gets a brief text frame ("here's the flow we walked through") and the CTA is a specific next step ("book 20 minutes").
• Launch page: the opener gets a headline above it. The proof moment gets a one-line caption.

Same demo. Three contexts. The core flow does not move.

Make the sales version easier to talk through

Trim friction. Remove any step that needs explanation and does not add proof. The sales demo should be something a founder can narrate live or drop into a follow-up email with one sentence of context. One obvious next step at the end, not three options.

Localize the parts that actually need it

Translated copy lives in `/demo/copy/[locale].json`. The flow pulls from it. Adding a new locale is a prompt: "translate the copy file to French, preserve all keys." The demo structure does not change. The agent handles the translation pass. One market, one prompt, no separate project.

Update the demo when the product changes without starting over

Patch the flow from the same branch as the product

The maintenance loop is simple: product change, identify affected demo assets and states, re-prompt the agent against the existing demo code, review, ship. Because the demo lives in the repo, the patch is a PR alongside the product change. The demo and the product ship together.

That is the concrete reason repo ownership beats a separate SaaS for this job: the agent that helps you ship the product can also keep the demo honest, in the same workflow, without a context switch.

Keep a small checklist for every release

Before every release, run this against `/demo`:

• Screenshots: any UI that changed?
• Scripted states in `/demo/states`: does the fixture still match current model output?
• Copy: any labels, button text, or feature names that changed?
• Voiceover: any narration that references outdated behavior?
• CTA: does the next step still make sense?

Five checks. Two minutes. The alternative is a demo that shows last week's product to next week's buyers.

Where Inkly comes in

The problem above is structural, not cosmetic: a demo goes stale because it lives inside someone else's SaaS, and every product ship turns into a re-record. The fix is not a better editor. It is a demo that is code you own, maintained by the same agent that ships your product.

Inkly is built on that premise. The demo is created as HTML code that lives in your repo. You bring your own agent — Cursor, Claude, Codex — and the three-prompt loop replaces the re-record cycle: prompt to create, prompt to update when the product changes, prompt to produce a variant for the next customer. HTML capture is available from the only tier there is, which is free. The tradeoff is real: you need a coding agent already set up. If you're building an AI product and shipping with Cursor or Claude, that is already true. If not, Supademo's all-in-platform flow may be the cleaner first step.

For everyone already in that workflow: build the demo as code you own and let the agent keep it current.

FAQ

Q: How do I turn a rough AI product into a demo that feels pitch-ready fast?

Pick one workflow your product handles end to end. Find the single moment where the model does something a buyer will find useful. Build the smallest demo that shows that moment clearly, opener, proof, CTA, and strip everything else. A rough product with a sharp demo of one job beats a polished product with a tour of twelve features.

Q: What should the demo show first so buyers immediately understand the value?

The first meaningful action in the workflow, not the home screen, not the settings panel. For most AI products, that is the moment the model responds: the output, the result, the flagged item. Start there. Everything before it is setup the buyer does not need to see.

Q: Should I use screenshots, animated text, GIFs, video, or code-based interactivity for my demo?

Screenshots for orientation. GIFs or short clips for showing behavior the buyer does not need to interact with. Code-native interactivity when the buyer needs to click through a believable flow that will live in multiple channels and stay accurate after the next product release. Most AI product demos need at least one code-native section. The moment the model responds is the one buyers need to feel, not just watch.

Q: How do I keep an AI demo believable when the product can hallucinate or vary output?

Identify which parts of the flow the model cannot guarantee. Put those parts in scripted fixtures, fixed outputs that represent realistic results. Label them as examples. Keep the live model calls only for the parts that are stable and impressive. On-screen narration that acknowledges simulated results builds more trust than a demo that implies live calls it is not making.

Q: How do I update the demo as the product changes without rebuilding it from scratch?

Keep the demo in your repo, in its own folder, with assets and scripted states beside the flow code. When the product changes, run the release checklist: screenshots, fixtures, copy, voiceover, CTA. Re-prompt your agent against the existing demo code for anything that changed. The demo patches in the same PR as the product change. No re-record, no separate tool, no starting over.

Conclusion

The repo-vs-SaaS choice is the whole game. If the demo lives next to the product, the agent that ships the product can keep the demo honest, same workflow, same branch, same five-minute patch cycle. If the demo lives in someone else's SaaS, every product change is a re-record you owe the next buyer.

Pick one workflow this week. Build the smallest demo that proves it. Put it in the repo.