Embed interactive demo in your app: The repo native way

Open your current demo in one tab. Open your live app in another. If they don't match, maybe a nav label changed, a modal moved, or a feature shipped that the demo doesn't show. The problem is not your update discipline. The problem is that your demo lives in someone else's platform, and every product change sends you back to their editor. This guide covers the repo native way to embed an interactive demo in your app shell: treat the demo like product code, keep it in the repo, and let your agent update it when the UI changes.

Why you should embed interactive demo in your app shell, not park it in a separate SaaS

The app tab and the demo tab should tell the same story

The two tab test takes ten seconds. If the tabs tell different stories, the demo is not part of the product. It is a snapshot of a product that used to exist. An embedded product demo that lives in a separate SaaS becomes a liability the moment you ship. The vendor's editor does not know your codebase changed. Your users do.

What changes when the demo is code you own

When the demo is a code artifact in your repo, it sits next to the components it mirrors. A folder like `/demo` or `/app/demo` next to `/app/components` makes the relationship clear:

The demo ships with the app. It gets reviewed in PRs. It rolls back with git. That is the shift: from a hosted asset you babysit in a vendor UI to a versioned artifact your team already knows how to maintain. Vercel's work on embedding Next.js apps inside external surfaces points to the same idea. When the artifact lives in your own codebase, you control the update path.

Build the first embed path with the least moving parts

Start with one surface: app shell, product page, or landing page

Do not pick three surfaces for the first interactive demo embed. Pick one. The right surface depends on your goal:

• App shell — if you are trying to reduce time to activation for new signups, put the demo inside the product, triggered after first login or on an empty state.
• Landing page — if you are trying to convert visitors who have not signed up, the demo belongs above the fold or directly below the hero.
• Product or use-case page — if you are targeting a specific persona or workflow, embed the demo as supporting proof on the page that describes that workflow.

Start with the one that maps to the metric you are actually watching this month.

Keep the first version boring enough to ship

One demo. One CTA. One clear action the viewer should take after watching. A `<iframe>` or a `<script>` tag pointing at your `/demo/index.html` is a valid first embed. The goal is to prove value before you add branching, personalization, or multiple tours. A demo that ships this week with no variants beats a polished multi-tour hub that ships in six weeks.

Where the lead capture should sit

Most demos should be ungated. Gate only when the viewer is already high intent, like on a pricing page, a "request a demo" CTA, or an in app upgrade prompt. The pattern that works is simple: show the full demo freely, then present a form at the end, or after a specific action inside the demo, to capture leads who completed it. Gating the entry kills completion rates. Gating the exit captures the people who were actually interested.

Put the demo code in the repo where engineering can touch it

A folder structure the team can actually live with

The demo code belongs in the repo, close to the product code it represents. A structure that works:

The `README.md` is not optional. It is the ownership contract: who updates the demo when the product ships, what the update path is, and how to test it before it goes live. Without it, the demo becomes the thing nobody touches because nobody knows whose job it is.

Who owns changes when product and marketing both care

The cleanest ownership model: engineering owns the demo code; marketing owns the copy and CTAs inside it. When the product UI changes, engineering updates the affected screens, or prompts the agent to do it. When the messaging changes, marketing edits the copy directly in the HTML, no ticket and no handoff. One home, one git history, one rollback path. The agent handles structural updates; the no code editor handles copy. Neither team needs to wait on the other for the thing they own.

Ship the same embed on product pages, use-case pages, and in-app surfaces

When the demo belongs above the fold

The demo earns above the fold placement when the visitor's main question is "does this product do what I think it does?" That is usually true on a homepage or a direct response landing page. On a use case page, the demo is supporting proof, not the headline. It belongs below the value proposition, after the reader has context for what they are about to see. In app, the demo works best as an empty state replacement or a first login modal, visible when the user has nothing to look at yet.

How multiple tours fit into one demo hub

A demo hub is a navigation problem, not a content problem. The failure mode is dumping every tour on one page and calling it a library. The clean version is one hub page with clear routing by persona or use case ("For engineers", "For founders", "For sales"), each linking to a focused tour that covers one job. Keep each tour to the smallest flow that proves the relevant point. A viewer who lands on the hub should be able to find their tour in under five seconds and reach a CTA within three minutes.

Keep the embedded demo synced when the UI changes every sprint

The before/after update path on one product change

Say the onboarding flow gains a new step between screen two and screen three. On a screenshot based tool, that means a full recapture of every screen from that point forward. The annotations, the hotspots, the CTA placement all need to move. On a code owned demo, the update path is: open the demo code, prompt your agent ("add a new screen between 02 and 03 matching the current onboarding step, update the nav links"), review the diff, commit. The mechanism is different in kind, not just in speed. PostHog's dashboards docs show the same idea from the analytics side: when the artifact is code native, sharing and embedding stay in sync with the underlying data without a manual export step.

How an agent update is different from re-recording

Re recording is linear: capture every affected screen, re annotate, re test, republish. An agent update is a diff: describe what changed, let the agent patch the relevant files, review the output. The agent does not need to see the whole demo to update one screen. That is the asymmetry. Re recording scales with the number of affected screens; an agent prompt scales with the complexity of the change description.

Versioning, QA, and rollback without drama

Version the demo the same way you version the product: branch, commit, tag. Before any demo update goes live, test it in staging against the current product build. Click through every step. Confirm every CTA resolves correctly. If a demo update breaks something, `git revert` is the rollback. No vendor support ticket, no "restore previous version" button buried in a settings menu. The demo is code, so the whole git workflow applies.

Measure whether the embedded demo earns its place

What to track after launch

Four metrics, in priority order: completion rate, clickthrough rate on the in demo CTA, lead capture rate at the gate, if you have one, and downstream conversion. Did demo viewers activate, upgrade, or close faster than non viewers? Set these up before you polish anything. An interactive demo embed with no tracking is just a guess about whether it is working.

How to tell if the embed is helping or just looking nice

The readout is simple: are viewers who complete the demo taking the next action at a higher rate than viewers who do not? If yes, the demo is shortening the path to conversion. If completion is high but downstream conversion is flat, the demo is interesting but not persuasive, and the CTA or the flow needs work. If completion is low, the demo is losing people before it makes the case. Look at where drop off happens and cut everything before that point.

Where Inkly comes in

The structural problem this guide keeps circling is that most demo tools make the demo a SaaS locked artifact. Every product change, every new customer, every messaging update sends you back to the vendor's editor. The demo and the product drift apart because they were never in the same place.

Inkly is built on the opposite premise: the demo is code you own, created through a three prompt agent loop, prompt to create, prompt to update, prompt to produce a variant. When the product ships a UI change, you re prompt the agent against the existing demo code. No re record. No recapture. The diff is reviewable, the commit is versioned, and the rollback is one `git revert`. When a new customer needs a branded variant, you re prompt off the same base code. Same flow, new logo, new sandbox data, in minutes.

The honest tradeoff: Inkly's MVP path is bring your own agent (Cursor, Claude, Codex). If you are not already running a coding agent, there is setup involved. But if you are, and most founders reading this are, the update path is a prompt and a commit, not a session in someone else's editor. Vibe-code your first demo and put it next to your product code this week.

FAQ

Q: What is the fastest way to embed interactive demo in my app or website without a long implementation cycle?

Capture or author one demo as an HTML file, drop it into a `/demo` folder in your repo, and embed it with a single `<iframe>` or `<script>` tag on the target page. Wire one CTA. Ship it. The whole path from zero to a live embed can close in a day. The polish and branching come later.

Q: How do I keep an embedded demo current as the product UI changes every sprint?

Keep the demo in the same repo as the product. When the UI changes, prompt your coding agent to patch the affected demo screens against the new UI. Review the diff, test in staging, commit. The update path is a prompt and a PR, not a recapture session in a vendor editor.

Q: Should the demo live in the marketing site, the app shell, or both?

Start with one. If your priority is converting visitors, start on the landing page. If your priority is activating new signups, start in the app shell on the empty state or first login screen. Once you have completion and conversion data from the first surface, expand to the second.

Q: What is the best workflow for a founder-builder who wants to launch quickly without engineering overhead?

Prompt your coding agent to author the demo as HTML from a description of the key flows, or use a Chrome extension to capture the live product as a starting basis. Drop the output into `/demo` in your repo. Embed it with one tag. Track completion with a basic analytics event. That is the full MVP. No vendor contract, no seat pricing, no editor to learn.

Q: How can a product engineer connect the demo to the product codebase so updates are easy to maintain?

Put the demo code in the same repo, in a `/demo` folder adjacent to `/app/components`. Add a `README.md` that names the owner and the update path. When product components change, the demo screens that mirror them are in the same PR context, so the engineer updating the component can update the demo in the same branch.

Q: How can an AI-native builder use tools like Cursor, Claude Code, or Codex to create and iterate the demo faster?

Use the three prompt loop: prompt to create the initial demo from a description of the product flow, prompt to update specific screens when the UI changes, and prompt to produce a branded variant when a new customer or use case needs a tailored version. Each prompt operates on the demo code as a file. The agent reads the existing HTML, applies the change, and writes the diff. No UI editor required.

Conclusion

Go back to the two tab test. If your demo is in your repo, the app and the demo stop drifting apart. The same PR that ships the product change can ship the demo update. If the demo is still in a vendor's SaaS, that gap will keep widening every sprint. Embed one real demo on one real surface this week. Wire completion tracking before you add a second tour. The polish is worth nothing if you do not know whether the first one is working.