Vibe coding demo: Keep it in your repo

Every vibe coding demo looks great on day one. You prompt an agent, it writes the screens, you send the link, someone clicks through. Then you ship a feature. Then you rename a nav item. Then you restructure the pricing page. Three releases later, the demo is showing a product that no longer exists, and the usual fix is to rebuild it from scratch in whatever SaaS tool you used the first time.

The real problem is where the demo lives. A vibe coding demo inside someone else's platform has to be rebuilt every time your product changes. Put it in your repo, and updates follow the same path as the app itself: prompt, edit, review, merge.

Here is the workflow.

Why a vibe coding demo breaks when it lives outside your codebase

The day-one demo is not the real test

First-capture speed is easy. Supademo, Arcade, Storylane, a raw agent prompt, all of them can get you a shareable demo in under an hour. The real test is the week after you ship something visible: a renamed button, a reworked flow, a new onboarding step. At that point, a demo trapped in a SaaS tool means opening the editor, finding every affected screen, and re-recording or patching each one by hand. The demo and the product become two separate things with two separate maintenance queues.

What the lock-in actually costs

The cost is not one re-record. It is the pileup after that. Every release creates a gap. Every gap needs a manual pass. And that pass happens outside the normal development workflow.

When a pricing page restructure ships on a Friday and the demo still shows the old plan names on Monday, somebody has to catch it, triage it, and fix it before the next prospect call. That somebody is usually the founder. Supadimo's own documentation describes re-capture as the standard path for structural UI changes, which means the overhead is built in.

Put the vibe coding demo next to the app code

The repo structure that keeps the demo honest

A repo-native demo has one job: stay close enough to the product that updating it is obvious. A simple layout that works:

The demo directory sits at the repo root, not in a separate repo and not in a shared drive. It is part of normal development: same `.gitignore`, same PR process, same branch rules.

Who owns the demo when the product ships

Engineers own the code path. Product marketing owns the story. The repo is where they meet, without Slack archaeology or "can you update the demo?" messages that disappear for two weeks. Mintlify built the same model for documentation — docs as code in your repo, maintained by the same people who maintain the product. The demo belongs in that same bucket.

Prompt to create the first vibe coding demo

Start from one short brief, not a blank page

An AI-built demo does not need a huge spec. It needs four things: the product goal the demo serves (investor call, customer pitch, onboarding), the user journey to show (one path, not the whole app), the output format (HTML screens, clickable, self-contained), and the constraint that the output lives in `/demo` and can be edited by any agent. That brief fits in five sentences. Hand it to Cursor, Claude, or Codex and let it write the first draft.

As Vercel's vibe-coding-platform documentation describes, the pattern is text prompt in, full application out. The same loop works for a demo.

Remix an existing project instead of starting over

If you already have a working branch with a previous demo version, start there. Point the agent at the existing `/demo` directory, describe what changed, and ask it to update instead of recreate. Iterating on a working scaffold is faster than starting from a blank page, and it tends to produce fewer weird surprises. The second prompt is often where the polished demo shows up.

Prompt to update the vibe coding demo after a release

Use the product diff as the input, not the old demo

When a release ships, the update prompt starts with the diff, not a description of what the demo currently shows. Open the PR or the release notes, identify the screens and flows that changed, and give the agent the changed files alongside the demo directory. Ask it to bring the demo in line with the shipped product. The agent can see both sides, the old demo code and the new product code, and reconcile them without a full rebuild.

PostHog's tutorial on vibe-coding with Claude Code describes this interaction model directly: you describe what you want in the context of the existing codebase, and the agent makes the targeted change. The same loop applies here.

What a good update prompt sounds like

Weak prompt: "Update the demo to match the new release."

Stronger prompt: "The nav item 'Workspace' was renamed to 'Projects' and moved from the top bar to the left sidebar. Update `/demo/screens/nav.html` and any screen that references the old label. The entry point is `demo.html`. Do not change the onboarding flow — only the nav."

The stronger version names the changed element, the behavior shift, and the file path to edit. It also says what not to touch. That is the difference between a targeted patch and a full regeneration.

Version the vibe coding demo like release code

Branch it before you change it

Demo changes deserve their own branch, not a direct commit to main. Create `demo/update-v2.3` before touching any screen, make the changes, and open a PR. That gives the team a chance to review the demo update before it ships with the release, the same gate the product code goes through.

Tag the demo to the release it matches

Add one line to `CHANGELOG.md` after every merge: which app release the demo was checked against, and the date of the QA pass. A tag like `demo-v2.3 — checked against app v2.3.1, 2025-06-10` means nobody has to guess whether the demo is current. When a new release ships, the first question is whether the demo tag matches.

Run a minimum QA pass before you publish

The release checklist that catches obvious drift

The minimum QA pass for a code-native demo takes ten minutes:

• Click through the main user path end to end.
• Check every label against the current product — nav items, button text, plan names.
• Confirm any sandbox data matches the current data model.
• Timestamp the pass in `CHANGELOG.md`.

That is it. The goal is not a full regression test. It is a drift check. Four steps, one reviewer, one timestamp.

What to do when the demo and product disagree

If the mismatch is a label or a copy change, patch it in place. If the flow changed — a step removed, a new screen added, a different user journey — regenerate that section from the new product code. If the demo would actively mislead a buyer about how the product works, hold the release until it is fixed. A wrong demo is worse than no demo.

Split ownership between founders, engineers, and demo owners

How the handoff works without extra meetings

Founders or growth leads define the story: which flow to show, which value to lead with, what the CTA is. Engineers keep the code path healthy: they review demo PRs, approve merges, and flag when a product change will break the demo. The repo holds the source of truth both sides edit. No meeting required. The PR comment thread is the handoff.

The one rule that keeps marketing from breaking the branch

Non-engineers can request changes in plain language — a Slack message, a GitHub issue, a comment on the PR. The actual change still moves through the repo and the review process. Marketing shapes the story; engineering approves the code. That boundary keeps the demo stable without slowing either side down.

Regenerate, patch, or retire the demo branch

When a patch is enough

Copy tweaks, label changes, and minor route updates should be patched in place. The demo still covers the same flow. Only the surface changed. One targeted prompt, one PR, done.

When the flow has changed too much

If the path, data shape, or core product logic changed, regenerate the demo from the new release instead of piling edits onto old assumptions. A demo built on the wrong structure turns into exception-handling forever. Start clean.

When to kill an old demo entirely

If the use case the demo was built for no longer exists, or if the demo keeps needing exceptions every release, archive it. Move the directory to `/demo/archive/`, note the reason in `CHANGELOG.md`, and stop maintaining it. A retired demo that is clearly labeled is better than a live demo that is quietly wrong.

Where Inkly comes in

The maintenance problem this article describes — demo trapped in a SaaS, every release creates a gap, every gap needs a manual pass — exists because the demo artifact and the product code live in different places with no shared update path.

The fix is a demo that is code you own, built by your agent, living next to your product. That is what Inkly is built on. You prompt to create the first demo, prompt to update it after a release, and prompt to produce a variant for the next customer. Same three-prompt loop, but applied to code that lives in your repo. When the nav renames, you point Cursor or Claude at `/demo` and the diff, and ask it to reconcile. No re-record. No SaaS editor. No separate maintenance queue.

The tradeoff is plain: Inkly's MVP requires you to bring your own agent — Cursor, Claude, or Codex. If you are not already in that workflow, the setup has a real cost. If you are, the demo lives in your repo and updates like product code.

FAQ

Q: How do you build a vibe coding demo that looks polished on day one and still stays current after product changes?

Build it as code in your repo from a short prompt brief, and update it from the product diff after each release. The demo stays current because it follows the same review and merge path as the app, not because someone manually checks it before every call.

Q: What workflow lets a product engineer update the demo like normal code instead of recreating it from scratch?

Branch, prompt, edit, review, merge. Point the agent at the changed files and the existing demo directory, write a specific update prompt that names the changed element and the file to edit, open a PR, and merge when the QA pass clears. It is the same path as any other code change.

Q: How can a founder or solo builder ship a demo quickly without locking themselves into a fragile SaaS prototype?

Use a code-native demo stack or an agent-generated repo artifact from the start. The first demo takes roughly the same time either way. The difference shows up the next time the product ships. A demo in your repo costs one prompt to update. A demo in someone else's SaaS costs a manual re-record pass across every affected screen.

Q: What should change management look like when product, engineering, and marketing all touch the demo?

One repo, one source of truth, one review path. Marketing requests changes in plain language; engineering reviews and merges the code. The PR comment thread replaces the coordination meeting. The `CHANGELOG.md` entry replaces the "which version is current?" Slack thread.

Q: How do you prevent the demo from drifting away from the shipped product as releases happen?

Tie each release to a demo check: run the update prompt from the diff, do the four-step QA pass, timestamp the result in `CHANGELOG.md`, and only publish when the demo tag matches the release. The timestamp is the signal. If it is older than the last release, the demo has not been checked.

Conclusion

The demo should behave like the product, not a side file nobody wants to touch. Put one demo branch in your repo this week. When the next release ships, run the update from the diff instead of rebuilding from scratch. That is the whole workflow, and it compounds every release from there.