Product demo for vibe coders: the demo as code

Open any guide on product demos for vibe coders and the first thing it covers is how to build a prototype fast: spin up a UI with Cursor, record a Loom, share the link. Fine for day one. Wrong problem for every day after. This article is about the demo-as-code system: a product demo for vibe coders that lives in the repo, updates with the app, and stays maintainable by the same AI coding agent you already use.

What a product demo for vibe coders actually is

The shortcut most guides take

Most guides treat vibe coding as a prototyping trick: get to something clickable fast, show it to someone, iterate. The demo gets pushed to the side. Record a Loom when you need to pitch, re-record when the product changes. That works once. By the third sprint, you're maintaining two separate things: the app and a demo that no longer matches it.

The repo-native version

A demo-as-code system puts the demo in the same place as the app. The demo folder sits next to your source code, versioned in git, and updated through the same workflow. When the product changes, the agent that touched the app can touch the demo. There's no separate tool to log into and no recording to redo. The demo is just more code, and your coding agent already knows how to edit code.

A repo tree makes this concrete:

The `/demo` directory is the whole system. Fixtures are the safe data layer. Routes are the clickable paths. Assets are the screens or components the viewer sees.

Vercel's overview of vibe coding describes the same agent-first development loop, with prompts driving code changes across the whole project. The demo is just another directory that participates in that loop.

Why recordings and standalone demo tools fall behind after the first release

When the UI changes and the demo does not

Ship a nav rename on a Friday. The recording you made last week still shows the old nav. A prospect opens it Monday and sees a product that no longer exists. The fix on a screenshot-based tool is a full recapture pass: open the tool, re-record every affected screen, re-annotate, re-publish. On a five-screen demo with two changed routes, that's not a quick edit. It's a rebuild.

That's the real cost of a demo tool, and it lands on every release. Capture speed wins trials, and every comparison guide leads with it, but none of them measure what happens the week after you ship.

What the update cost looks like across tool types

Screenshot-based tools like Supademo capture static images of your UI. Any structural change, like a renamed nav item, a new modal, or a restructured onboarding flow, requires recapturing every affected screen. There's no in-place layout edit because the demo is a stack of images, not a live render.

HTML-clone tools like Storylane and Navattic capture a live copy of the DOM. Text and data edits work in place; structural changes still require a re-clone of the affected pages. Better than screenshots for minor copy changes, same recapture cost for anything that touches layout or navigation.

Code-owned demos, the demo-as-code approach, re-render from the actual code. An update is a prompt to the agent: "the nav now has a Settings item between Reports and Help - update the demo path." The agent edits the demo code the same way it edits the app code. No recapture, no re-clone.

For an interactive product demo that has to stay current across weekly releases, the update mechanism is the decision.

Build the demo-as-code system: app code, demo code, and the agent

How the three-part workflow fits together

The system has three moving parts: the app code, the demo code, and the agent. The app changes when you ship. The demo code describes what the viewer sees and clicks. The agent is the bridge. When the app changes, you prompt the agent to update the demo to match.

The dependency chain is simple: app change → identify affected demo paths → agent prompt → demo code updated → re-publish. No separate tool, no manual re-record. The agent already has context on the app change, since it made it, so the demo update prompt stays short: "the onboarding flow now skips the team-size step - update the demo fixture and the route."

The folder structure that keeps the demo maintainable

A maintainable demo-as-code setup looks like this:

Fixtures hold the data layer separately from the UI layer. Routes define the clickable paths. The config ties it together and defines what gets published. When the app changes, the agent touches routes and fixtures, not assets, unless a screen capture needs refreshing. That separation is what makes the update targeted instead of total.

PostHog's guide to vibe design makes the same point for product engineering: structure the work so the agent has a clear, bounded scope. The demo folder is that boundary.

Keep the demo current every time the product ships

The release-to-demo checklist

Every release that touches the UI should trigger a four-step demo check:

• Identify changed screens. Which routes in `/demo/routes` reference the changed UI? A git diff on the app code tells you.
• Update the demo path. Prompt the agent with the specific change: what moved, what was renamed, what was added or removed.
• Test the entry flow. Run through the demo start to finish as a viewer. Catch broken steps before a prospect does.
• Re-publish. Push the updated demo code. If it's hosted, the new version is live immediately.

Four steps, and the agent handles step two. The whole check takes minutes, not an afternoon.

Where people forget to sync

The common failure points after a release:

• Hard-coded copy in fixtures. If the demo data references a feature name that just changed, the demo shows the old name.
• Old navigation in routes. A renamed nav item in the app isn't automatically renamed in the demo route. The agent has to be told.
• Stale screenshots in assets. If the demo uses any static screen captures alongside the code, those don't update automatically. Keep the assets folder minimal.
• Entry state assumptions. The demo often assumes a specific starting state, like logged in, onboarding complete, or a specific plan selected. A product change that affects that state breaks the demo silently.

The fix for all of these is the same: run the release checklist before the demo is shared again, not after a prospect sees something wrong.

Make the demo safe: fixtures, fake users, and no real customer data

What demo data should look like

Demo fixtures should be believable but synthetic. A realistic company name, a plausible usage pattern, a dashboard that looks like a real account, none of it sourced from production. The GDPR guidance on pseudonymisation is the right mental model: data that reads as real but cannot be traced back to a real person or account.

In practice: a `base.json` fixture with a fictional company ("Acme Corp"), seeded metrics that match the product's typical range, and user records with made-up names and email domains. Enough realism to sell the flow, zero exposure if a prospect shares a screenshot.

How to generate multiple prospect paths from one base

One base fixture, multiple overrides. A `prospect-a.json` imports from `base.json` and overrides the company name, logo, and one or two metrics relevant to that prospect's industry. The demo route stays the same. Only the data layer changes.

That gives you one codebase and multiple demos. A founder-led sales demo, a PMM walkthrough, and a solutions engineer deep-dive can all run from the same `/demo` directory with different fixture files. No duplicated environments, no separate recording per prospect.

Publish the demo where buyers already are

Landing page, DM, or sales call

Three surfaces, three slightly different requirements:

• Landing page: embed polish matters. The demo should load fast, start in a clean state, and not require a human to guide it. A static entry point with a clear first click is enough.
• DM or async share: a direct link to the hosted demo. Speed is the priority because the prospect clicks from their phone. Keep the entry flow short and the first screen immediately recognizable as the product.
• Live sales call: you control the pace. The demo can be longer and branch into detail. What matters is that it matches the current product. A stale demo on a live call is the worst version of the problem.

What makes it pitch-ready without extra overhead

A versioned demo is pitch-ready when it has three things: a clean starting state, realistic fixture data, and a path short enough to complete in under two minutes. None of these require extra tooling. They come from the structure. The entry state is defined in the config. The data is in the fixtures. The path length is a routing decision.

First Round's piece on Linktree using AI to accelerate product work makes the same point about AI-native workflows generally: the speed advantage compounds when the artifact is structured so the agent can maintain it, not just create it. A demo that lives in the repo is that kind of artifact.

Where Inkly comes in

The structural problem this system solves is simple: most demo tools make the demo a recording inside their SaaS. Every product change means going back to their editor, recapturing screens, republishing. The demo and the product become two separate things that drift apart.

Inkly is built on the opposite premise: the demo is code you own, off-platform, living next to your product. You capture once with a Chrome extension, same speed as Supademo on the first demo, and from that point on, updates are agent prompts, not re-records. When the nav changes, you tell the agent. The demo code updates the same way the app code does.

The tradeoff is straightforward. Inkly requires a coding agent (Cursor, Claude, Codex) and a repo workflow. If you're not already operating that way, the bring-your-own-agent path adds setup. But if you're a vibe coder founder who already lives in Cursor, the demo just becomes another directory your agent maintains. You can ship a pitch-ready demo from the same workflow you use to ship the product.

FAQ

Q: What is the best way to build a product demo that lives in code and updates with the app?

Put the demo in a `/demo` directory inside the app repo, with fixtures, routes, and assets as separate concerns. Use the same coding agent (Cursor, Claude, Codex) that maintains the app to maintain the demo. When the product ships a UI change, prompt the agent with the specific delta. It updates the demo code the same way it updates the app code. No separate tool, no re-record.

Q: How do you keep a demo current every time the product ships without rebuilding it from scratch?

Run a four-step check on every release: identify which demo routes reference changed UI, prompt the agent to update them, test the entry flow end-to-end, and re-publish. The agent handles the edit; you handle the check. Because the demo is code, the update is targeted. Only the affected routes change, not the whole demo.

Q: What demo structure works best for a vibe coder founder versus a PMM or solutions engineer?

A founder wants repo ownership and agent-driven updates, the full demo-as-code system. A PMM usually cares more about branching, one base demo with multiple prospect-specific paths, and presentation control, like clean embeds and fast load times. A solutions engineer needs deeper branching and the ability to show different flows per account without duplicating the environment. The same folder structure serves all three; what changes is how many fixture overrides you maintain and how much the entry flow branches.

Q: How can you make an interactive demo feel pitch-ready without adding maintenance overhead?

Three things: a clean entry state defined in the config, realistic fixture data that reads as a real account, and a path short enough to complete in under two minutes. None of these require extra tooling. They're structural decisions made once. The demo stays pitch-ready because the agent keeps the routes current; the polish comes from the structure, not from re-recording.

Q: What should be in a demo codebase so it is easy to version, test, and deploy alongside the product?

At minimum: a `/fixtures` directory with a base data file and per-prospect overrides, a `/routes` directory with one file per demo flow, an `/assets` directory for any static captures, and a `demo.config.ts` that defines the entry point and published paths. Keep fixtures and routes separate. That separation is what makes updates targeted. Add a simple smoke test that runs the entry flow before publish. It catches broken steps before a prospect does.

Conclusion

A demo that lives in the repo is a small amount of structure up front: a folder, a fixture file, a config. What it stops being is a separate project you have to maintain in parallel with the app. Every release that used to mean a re-record becomes a prompt. Every per-prospect variant becomes a fixture override, not a new recording session.

Pick one product flow this week, onboarding, the core action, the dashboard, and turn it into a versioned demo path. Get the folder structure in place, seed one fixture, define one route. That's the whole system. The agent handles the rest from there.