AI native demo: Build it in your repo

Open your current demo in one tab and your live product in another. Scroll through both. Count the things that don't match: the button label that moved, the nav item you renamed last sprint, the onboarding step you cut three weeks ago that's still in the demo like it's load-bearing. That mismatch is not a tooling accident. An ai native demo is code you own in your repo, not a recording trapped in someone else's SaaS. The gap between those two things is the gap between a demo that drifts and one that stays honest.

Open the demo next to the product and look for the mismatch

The screenshot that makes the problem obvious

Pull up the demo artifact and the live product side by side. The first thing you'll spot is usually a label, something you renamed because the old name confused users, now immortalized in the demo. That's not a cosmetic problem. A prospect who sees the old label and then hits the live product notices the seam. The demo promised one product; the product delivered another.

Why hosted demo tools force the mismatch

When the demo lives inside a vendor's SaaS — Supademo, Arcade, Storylane — it has its own change path, separate from your codebase. You ship a UI change and now there are two things to fix: the product and the demo. The demo has no way to know the product changed. Nobody pings it. It just sits there showing last sprint's UI until someone goes in and re-records it. That second fix is the hidden tax on every release.

Create the first ai native demo from your codebase

The fastest path to a code-native demo starts narrow. Not the whole app. One flow.

Start from one flow, not the whole app

Pick the buyer-visible path that closes the most questions in a demo call: the core activation step, the key report, the moment the product clicks. Keep it to five or six screens. The tighter the scope, the cleaner the AI output and the easier the review pass. A demo that tries to show everything shows nothing.

Let the agent scaffold the demo, then trim it

Point your agent (Cursor, Claude, Codex) at the relevant product code and ask it to build the demo flow as HTML. The first draft will be close, but not ready. It'll include screens that are off-brand, steps that are noisy, or copy that's technically accurate but too broad for the buyer's job. Your job is the edit pass: cut anything that doesn't serve the specific story and tighten the copy to match what you'd actually say on a call. PostHog's take on S-tier demos makes the same point. The best demos are ruthlessly scoped, not comprehensive. The agent handles the scaffolding; you handle the judgment.

Use synthetic data and scripted voiceover without faking the product

Fake data belongs in the demo. Real customer names don't. Made-up product behavior does not. Use synthetic company names, realistic-looking numbers, and placeholder email addresses. Anything that makes the demo feel lived-in without inventing a feature the app doesn't have. Voiceover follows the same rule: script it against what the product actually does, let the agent generate a first-pass narration from the demo code, then review it for accuracy before it ships.

Decide what AI owns and what humans review in an ai native demo

Good AI jobs are the boring repeatable ones

The agent should own scaffolding, copy drafts, data shaping, and first-pass localization. These are repeatable, low-stakes, and cheap to review. Scaffolding from a prompt is faster than building screen by screen. Copy drafts from the demo code are faster than writing from scratch. First-pass translation from the same artifact is faster than forking the demo into a separate localized version. Let the agent do the volume work.

Humans still need to check the trust-sensitive parts

Review anything that affects what the buyer believes about the product: pricing claims, feature availability, onboarding steps that imply a workflow the app doesn't support, analytics events that fire on the wrong trigger. These are not the agent's job. A wrong pricing claim in the demo is not a demo problem. It's a trust problem that lands in the sales call.

The review rule that keeps the demo honest

One test before any demo ships: does this step, if wrong, embarrass the team on a live call? If yes, a human signs off. That's the whole rule. It's not about perfection. It's about not sending a prospect into a call with a demo that contradicts the product they're about to see. Stripe's work on AI agent reliability makes the same point about agent-built integrations. The agent handles the construction, but the verification gate is human. Same principle applies here.

Keep the demo aligned when the product ships every sprint

Treat the demo like a code path, not a deliverable file

When the demo is code in your repo, it moves through the same habits as the product: branches, pull requests, release notes. A UI change that touches the demo path shows up in the diff. The person reviewing the PR sees it. The demo doesn't drift silently. It drifts visibly, in the same place you're already looking.

Use version control to catch drift before customers do

Branch the demo update alongside the product change. The review step is the same: does the demo still match the product on this branch? If not, fix it before merge, not after a prospect call. Standard version control practices apply here exactly as they do to any other code-owned asset. The repo-owned demo inherits that discipline for free.

The update prompt that replaces re-recording

Say you rename a nav label from "Reports" to "Insights." On a screenshot-based tool, every screen that shows the old label needs a fresh capture pass. On a repo-owned demo, you re-prompt: "Update the demo — the nav label 'Reports' is now 'Insights' throughout." The agent edits the demo code in place. No re-record, no click-by-click fix, no second pass through the annotation layer. The change lands once, in the same place the product change landed.

Add analytics, localization, and sandbox steps without breaking the workflow

Track engagement where the demo actually runs

An interactive demo in your repo can fire analytics events the same way your product does, because it's code, not a media file. Wire view events, step-completion events, and drop-off points to whatever you're already using (PostHog, Plausible, your own pipeline). The team sees starts, completions, and where buyers exit, without bolting on a separate dashboard tool. The demo generates the same kind of signal as the product.

Localize the text without forking the demo

Translation and voiceover are layers on top of the same artifact, not separate demos. Prompt the agent to produce a localized variant: swap the copy, regenerate the voiceover, keep the flow identical. One base demo, multiple audiences, no clone farm to maintain. When the product changes, you update the base and re-prompt the variants. One change path, not one per locale.

Use sandboxed flows when the buyer has to click around

Some buyers want to explore before the call ends. A linear walkthrough works for a pitch. A sandboxed environment works for a technical buyer who wants to poke at the product. When the demo is code you own, a sandbox is a scoped, explorable version of the same artifact: personalized data, safe boundaries, no live database. Build it from the same repo-owned base, not as a separate tool.

Ship one demo that sales, product, and marketing can all use

Sales needs speed, product needs accuracy, marketing needs reuse

Sales wants to personalize the demo for the next prospect without rebuilding it. Product wants the demo to reflect the current build, not last quarter's. Marketing wants to embed the same artifact on the launch page without maintaining a separate version. A repo-owned ai native demo satisfies all three, because the artifact is one thing, not three copies drifting apart in three tools.

Put ownership in the repo, not in a shared folder

A demo in a shared Notion doc or a vendor SaaS has no clear owner, no change path, and no way to know when it's out of date. A demo in the repo has a file, a commit history, a branch, and a reviewer. Ownership is what makes a demo maintainable, not the tool, not the process, just the fact that it lives somewhere with a clear change path.

What changes when everyone uses the same artifact

Fewer stale assets. Fewer off-brand edits made by whoever had access to the vendor account last. A cleaner handoff from launch demo to customer follow-up, because the artifact the sales team uses is the same one that shipped, not a copy someone exported three weeks ago. The demo stays honest because it has one home and one update path.

Where Inkly comes in

The structural problem this article described — a demo that lives in a vendor's SaaS with its own change path, disconnected from the product — is not a process problem. It's an artifact problem. The demo is the wrong kind of thing. A recording in someone else's cloud cannot move with your product. Every sprint that changes the UI creates a second fix.

Inkly is built on the idea that the demo should be code you own, living next to your product, authored and maintained by your own coding agent. The three-prompt loop — create, update, produce variants — replaces the three things that historically killed demos: re-recording for updates, re-recording for new customers, and the silent drift between the demo and the live product.

The honest tradeoff: Inkly's MVP path is bring-your-own-agent (Cursor, Claude, Codex). If you're not already working with a coding agent, there's setup before the workflow clicks. But if you're already prompting your way through the product, the demo becomes code you maintain the same way: one prompt, no re-record, no second tool to sync.

FAQ

Q: What does an AI-native demo actually mean for a repo-first founder or product engineer?

It means the demo is code in your repo, created and updated through the same workflow as the product. Not a recording in a vendor's SaaS. Not a file in a shared folder. A code-owned artifact your agent can re-author from a prompt whenever the product changes.

Q: How do you create a polished demo from a product codebase without heavy tooling overhead?

Pick one buyer-visible flow, prompt your agent to scaffold it as HTML from the relevant product code, then do one edit pass to cut anything off-brand or too broad. The agent handles the volume; you handle the judgment. Five or six screens, scoped tight, is enough for a first demo that closes questions on a call.

Q: How can an AI-native demo stay aligned with a product that changes every sprint?

Version control is the mechanism. When the demo is code in your repo, a UI change shows up in the diff alongside the product change. You update the demo on the same branch, review it in the same PR, and merge it at the same time. The demo doesn't drift silently. It drifts visibly, where you're already looking.

Q: What parts of the demo can AI automate safely, and what still needs human review?

AI handles scaffolding, copy drafts, data shaping, and first-pass localization. That's repeatable work that's cheap to review. Humans review anything that affects what the buyer believes: pricing claims, feature availability, steps that imply a workflow the product doesn't support. The test is simple: if this step is wrong, does it embarrass the team on a live call? If yes, a human signs off.

Q: How should a developer advocate structure a demo so it is maintainable and reusable across launches?

One repo-owned artifact, one clear flow, one update path. No duplicate copies per launch. Prompt the agent to produce variants off the same base for each audience or locale. The base demo updates once when the product changes; the variants re-prompt from the updated base. Ownership lives in the repo, not in whoever had access to the vendor account last.

Conclusion

Pick one real product flow this week: the activation step, the key report, whichever moment closes the most questions on a call. Build the demo from the repo. Then push a product change and watch what happens to the demo. If the demo is a recording in a vendor's SaaS, you'll fix it separately, manually, after the fact. If it's code next to the product, you'll update it in the same diff. That's the test. The demo should live next to the code, not beside it in a tool that doesn't know the product shipped.