Personalized demo from prompt: Build it in your repo

Demo tooling splits into two groups that matter more than any feature list: tools that keep the artifact inside their SaaS, and tools that emit code you own. The first group makes every update a manual job inside someone else's editor. The second turns your demo into a file your agent can touch. This article is about building a personalized demo from prompt in the second group, inside Cursor, Claude Code, or Codex, next to your product code where it belongs.

Why a personalized demo from prompt belongs in your repo

The artifact trap

The usual demo tool flow is simple: you capture screens, the tool stores them, you share a link. That link points to a recording that lives inside the vendor's infrastructure. When your product changes, maybe a nav item moves, a label updates, or a feature ships, you open the vendor's editor and fix it by hand, screen by screen.

Per-customer personalization makes this worse. A new prospect wants their logo on the dashboard, their data in the fields, their use case in the copy. On a capture-first tool, that means another pass through the editor, or another full re-record. You are not personalizing a demo. You are rebuilding it.

What changes when the demo is code

When the demo is code in your repo, the prompt is the source of the first version and every version after it. Your agent reads the demo file the same way it reads any other file. A product change triggers a re-prompt, not a re-record. A new customer triggers a variant prompt, not a rebuild.

The practical shift is pretty plain: demo files sit beside your app code. A UI change in `src/components/Nav.tsx` and a matching prompt to update `demo/nav-flow.tsx` use the same workflow, the same agent, and the same review cycle. The Vercel AI Accelerator Demo Day teams building agent-native products are already treating demos this way. The demo is just another artifact the agent maintains.

Feed the prompt the right context before you generate anything

The minimum prompt inputs

A prompt that says "make me a demo" produces a generic output because the agent had to invent the rest. Give it real context:

• Audience — who is watching, what they already know, what they are trying to decide
• Product surface — which screens, which flow, which feature set
• Demo goal — what the viewer should do or believe by the end
• Required UI states — the specific screens and states the demo must show
• Branch logic — if the viewer is an enterprise buyer vs. a solo user, what changes
• Hard exclusions — the one thing the demo must not show, like a half-shipped feature, a competitor comparison, or a pricing page that changed last week

A prompt-built demo is only as accurate as the context you feed it.

The prompt structure that scales

Copy that schema, fill it in before you open Cursor, and the agent has enough to generate a first version that is actually about your product.

What happens when you leave context out

The most common failure is that the agent gets the product surface right but the audience wrong. You are building a demo for a technical buyer evaluating an API. You leave out the audience field. The agent defaults to a marketing-friendly walkthrough that shows the dashboard, skips the docs integration, and ends with a "Start free trial" CTA. The product surface is correct. The demo is useless for the call you built it for.

According to PostHog's product analytics documentation, capturing the right events starts with knowing which user actions you actually care about. The same principle applies to demos. Know the audience before you define the flow.

Generate the first personalized demo from prompt in Cursor, Claude Code, or Codex

Cursor as the fast path

Open your repo in Cursor. Drop the prompt schema into the Composer window with a target file path: `demo/[persona]-flow.tsx`. Accept the generated structure, then check three things right away: does the flow order match how the product actually works, do the UI states reference real component names from your codebase, and does the CTA match what you want the viewer to do. Fix those three before you touch anything else.

Cursor's Composer can read your existing component files if you reference them — `@src/components/Dashboard` — which means the AI-generated demo can pull real UI structure instead of inventing it.

Claude Code and Codex as code editors, not demo platforms

Claude Code and Codex are not hosting the demo for you. They are writing the demo code that you then host, version, and maintain inside your repo. The distinction matters: the output is a file, not a link. You own the file. You version it with git. You update it with another prompt.

Both tools work well for the first generation pass. Claude Code handles longer context windows, which helps when you feed it product docs alongside the prompt schema. Codex is tighter for structured output when you have a clear file format target.

The first pass should be ugly but complete

Version one of an AI-generated demo is not meant to be polished. It is meant to compile, branch correctly, and cover every required UI state. Polish is a second pass. On the first pass, ask a simple question: does the demo follow the right path for the right audience, and does it end in the right place? If yes, the structure is right and you can refine from there. If not, fix the prompt before you touch the output.

Shape the demo code so product changes are easy to absorb

A file structure that keeps personalization local

A repo-native demo that mixes shared flow logic with per-persona copy in the same file becomes a maintenance problem the first time you need to update one without touching the other. A minimal structure that avoids this:

The shared flow never changes when you update copy for one persona. The persona file never changes when you update a UI state in the base flow. Your agent edits the right file without touching the wrong one.

Map docs and UI states into named fields

One-off text blocks inside demo files are the first thing to go stale. Instead, pull your product docs, UI state descriptions, and key copy into named fields the agent can reference and reuse:

When the product ships a change to the dashboard, you update `dashboardLoaded` and re-prompt against the base flow. The agent knows exactly which state changed and what it looks like now.

Update the personalized demo when the product ships a change

What changes need a re-prompt

Not every product change needs a full demo refresh. Copy tweaks, like a button label, a tooltip, or a pricing line, are single-field edits your agent can patch in one prompt: "Update the CTA in `enterprise.ts` from 'Request access' to 'Start your pilot'." State changes, like a new screen added to the onboarding flow or a feature moved to a different nav location, need a targeted re-prompt against the affected section of `base-flow.tsx`. Flow changes, like a step removed, a branch restructured, or the demo goal itself shifted, need a wider refresh and a re-read of the full prompt schema before you regenerate.

The before-and-after diff that matters

Say your product moves the integrations panel from the sidebar to a top-level nav item. The demo currently shows a sidebar click as step three. The re-prompt: "The integrations panel is now a top-level nav item, not a sidebar item. Update step three in `base-flow.tsx` to reflect the new location. Keep the branch logic for enterprise vs. SMB unchanged."

The agent produces a diff. You review the diff, not the whole file. If the diff touches only step three and leaves the branch logic intact, it is correct. Merge it. The demo now matches the shipped product, with no re-record and no manual click-by-click fix. This is what Stripe describes as the agent-era workflow: the artifact and the product stay in sync because the agent can read both.

Test the demo before you send it to prospects

The QA checklist that catches bad demos

Before any interactive demo goes to a prospect, run through this in order:

• Copy accuracy — every label, CTA, and product name matches the live product right now
• Flow order — the demo path matches the actual product flow, not last month's
• Branch logic — each persona or audience branch reaches the right endpoint
• Dead ends — every clickable element goes somewhere; no broken states
• CTA alignment — the final action matches what you want the viewer to do after watching
• UI state accuracy — the screens shown are states the live product can actually reach

The easiest demo failures to miss

Stale labels are the most common. A feature was renamed in the product three sprints ago and the demo still uses the old name. Wrong audience framing is the second. The copy says "your engineering team" but the demo is going to a VP of Sales. Branch failures are the hardest to catch. The enterprise branch looks correct until the viewer clicks the upgrade prompt and lands in the SMB flow. Run the demo as the prospect, not as the builder who made it.

Where Inkly comes in

The problem this article describes is straightforward: a demo drifts away from the product every time something ships, then has to be rebuilt from scratch for every new customer because the demo is stored as a recording inside someone else's platform. The fix is structural. Make the demo code you own, living next to your product, editable by the same agent that edits your app.

Inkly is built on that premise. The three-prompt loop — prompt to create, prompt to update, prompt to produce a variant — runs against demo code in your repo, not against a recording in a SaaS editor. A UI change means a re-prompt, not a re-record. A new customer means a variant prompt off the same base code, not a rebuild. HTML demos are available from the only tier there is (free), with no seat cap on creators, so no Growth plan and no sales call. The one honest tradeoff is that you bring your own agent: Cursor, Claude Code, or Codex. The in-app hosted agent is on the roadmap, not shipped yet. If you already have a coding agent in your workflow, the demo lives in your repo from the first prompt.

FAQ

Q: How do I turn one prompt into a personalized demo that matches my product and audience?

Fill the prompt schema before you generate anything: goal, audience, product facts, required UI states, allowed personalization, and output format. The agent produces a generic output when any of those fields are missing, especially audience and required states. One complete prompt produces a first version that is structurally correct. Polish is a second pass.

Q: What context should I feed the AI so the demo stays accurate to my product?

The highest-value context sources are your product docs, a list of the exact UI states the demo must show, the tone and vocabulary your product uses in-app, and the personalization fields that vary per viewer, like logo, company name, and sandbox data. These keep the output grounded in what the product actually does rather than what the agent assumes it does.

Q: How do I generate the demo inside Cursor, Claude Code, or another coding workflow?

Open your repo, drop the prompt schema into Cursor Composer or Claude Code with a target file path, and reference your existing component files so the agent pulls real UI structure. The output is a file in your repo, not a link in a SaaS platform. Version it with git, review it like any other PR, and update it with another prompt when the product changes.

Q: How do I keep the demo aligned when features, UI, or messaging change?

Separate copy, UI states, and flow logic into distinct files so the agent can edit the right one without touching the others. When a change ships, re-prompt against the affected file only. Review the diff, not the whole demo. The demo stays current because it is code your agent can read and edit, the same way it reads and edits the rest of your codebase.

Q: What parts of the demo can be personalized safely without rebuilding everything from scratch?

Safe personalization layers: copy, like labels, CTAs, company name, and persona-specific framing; data fields, like logo, sandbox values, and usage numbers; and branch endpoints, like which CTA a given audience sees. Structural flow changes, like a step removed, a branch restructured, or the demo goal itself shifted, need a wider re-prompt and a re-read of the full prompt schema. Keep personalization in the content and data files; keep the shared path in the base flow file.

Conclusion

The point of building a personalized demo from prompt is not that the first version is fast to generate. It is that the demo now lives where the product lives, and your agent can keep them in sync. Generate one demo from prompt this week using the schema above. Then push a UI change through your product and re-prompt the demo against it. If the diff is clean and the demo matches the live product in under ten minutes, the workflow is holding. That is the test that matters.