Sandbox demo architecture for repo native products

Open your current sandbox demo in one tab and your live product in another. Compare them screen by screen. If they match, your architecture is working. If they don't, and they usually don't, the problem is not the demo tool you picked. It is that the sandbox demo was built once and then the product kept shipping.

A sandbox demo only works if it stays tied to the shipped product without turning into a second system. The cleanest way to do that is to make it a repo native layer: the demo lives next to the product code, gets seeded with realistic data, resets cleanly, and gets maintained by the same agent workflow the team already uses. That is what this article covers.

What a sandbox demo actually is in product engineering terms

The controlled replica, not the live product

A sandbox demo is a controlled interactive replica of your product. The buyer clicks through the real UI, fills in real fields, and sees realistic data, but none of it touches production, creates real accounts, or runs against a live database. The point is simple: let people explore without risking anything. They get a feel for the product; you get a signal on what they actually care about.

This is not the same as a generic trial environment. A trial is your real product with a free tier constraint. A sandbox demo is a curated slice of the product, seeded with data that makes the right features visible and scoped so the buyer cannot wander into a half built corner and lose confidence.

How it differs from a live sandbox, free trial, or walkthrough

A live sandbox is a real instance of your application running in a non production environment, with the full feature set, real infrastructure, and real state. Buyers can break it, leave dirty data, and hit edge cases you have not polished. It is expensive to maintain and hard to reset cleanly.

A free trial is the live product with access limits. The buyer is a real user. The data they create is real. The experience is unguided.

A walkthrough — the kind Supademo or Arcade produce — is a recorded or cloned snapshot of the UI. The buyer clicks through a guided path, but they are not actually running the product. There is no real state, no real data model, and no real interactivity beyond what the recording captured.

A sandbox demo sits between the walkthrough and the live sandbox. The buyer is running something close to the real product, with real interactivity, but the environment is controlled: seeded data, isolated state, and a reset path that wipes the session cleanly. PostHog's handbook on building sandboxes for demos describes this well. The sandbox carries real risk, like data exposure and state leakage, that a passive walkthrough does not, which is why the architecture matters.

Build the sandbox demo as a repo-native layer, not a separate product

The architecture layers you actually need

A repo native demo architecture has six layers:

• Product source of truth — the same codebase that ships to production. The demo renders from this, not from a fork.
• Demo layer — a thin configuration or route that puts the app in demo mode: feature flags, route guards, or a demo specific environment variable that gates real API calls.
• Data seed — a script that populates the demo database with realistic synthetic records before each session. Users, accounts, events, workflows, whatever makes the product look lived in.
• Reset path — a teardown script or API call that wipes demo state after a session ends, so the next viewer starts clean.
• Analytics hook — event tracking on demo specific actions: session start, feature interaction, CTA click, drop off point.
• Agent workflow — the loop that keeps the demo current. When the product ships a UI change, the agent updates the demo layer and re seeds the data, instead of making a human re record screens.

Why the demo belongs next to the code that ships

When the demo is a separate SaaS artifact, like a Supademo recording or an Arcade clone, it decouples from the product the moment you ship. A nav rename, a new onboarding modal, a restructured settings page: each one makes the demo wrong, and fixing it means re recording or hand editing in someone else's UI.

A repo native demo gets updated the same way the product does: a code change, a prompt to the agent, a diff review. The demo layer is thin enough that most product changes propagate automatically. The ones that do not are explicit, like a changed route or a new seed record, and they show up in the same PR the feature ships in.

A web app sandbox demo architecture diagram

For a web app, the repo structure looks like this:

• `/app` — product source, shared with production
• `/demo` — demo entry point: environment config, feature flag overrides, route guards that block non demo paths
• `/demo/seed` — seed scripts: one file per entity type (users, accounts, events), deterministic output so every session starts identical
• `/demo/reset` — teardown script: drops demo scoped records, resets counters, clears session tokens
• `/demo/analytics` — event emitter: wraps the product's existing analytics client with a demo session identifier so demo events stay separate from real user data

The agent workflow sits outside the repo structure. When the product ships, a prompt to Cursor or Claude points at `/demo` and asks it to reconcile the demo layer with the updated routes and components. The diff is small because the demo renders from the same source. It is not a parallel implementation.

Use different implementation paths for web app sandbox demos and mobile demos

Why web demos are the easier ownership win

A web app sandbox demo lives in the browser. The distribution layer is a URL. When the product ships a change, the demo re renders from the updated code at the next page load. No packaging. No build artifact. No device context. The reset path is a server side script or a database wipe behind an authenticated endpoint. The agent can update the demo layer, re seed the data, and push to a preview URL in the same workflow it uses for any other code change.

This is why web demos are the natural fit for repo native architecture: the artifact and the product share the same runtime, the same deployment pipeline, and the same agent toolchain.

What changes when the product is mobile

Mobile app sandbox demos need a different distribution story. The demo cannot just re render from a URL. It has to be packaged as a build artifact (APK, IPA, or a web view wrapper), distributed through TestFlight, an internal MDM, or a device specific download link, and installed on a device or simulator before the buyer can interact with it.

That means UI changes do not propagate automatically. A changed screen requires a new build, a new distribution step, and possibly a new install on the buyer's device. The reset path is harder too: clearing app state on a mobile device is not a server side script.

For mobile products, the practical answer is usually a web view wrapper that renders the demo in a browser like environment, or a separate web based demo that mirrors the mobile UI closely enough to communicate the product without requiring a device install. Expo's web preview flow is one example of how teams bridge this gap. The demo runs in a browser while the real product ships as a native app.

Seed realistic demo data without leaking anything risky

The data model the demo needs to feel real

The demo needs enough data that the buyer recognizes their own workflow in it. For a B2B SaaS product, that usually means two or three user accounts with distinct roles, one or two organizations with realistic names and sizes, a set of recent events or activity records that make the dashboard feel active, and any workflow state the product's key features operate on, like open tasks, pending approvals, or in progress projects.

The goal is buyer recognition, not fake fullness. A dashboard with 10,000 synthetic records and no coherent story is harder to navigate than one with 20 records that tell a clear story.

Synthetic, masked, and customer-like data

Three options, each with a different tradeoff:

Synthetic data is generated from scratch: fake names, fake companies, fake email addresses, deterministic IDs. It is the safest option because no real customer information ever enters the demo environment. The risk is that it can feel obviously fake if the generator is naive, with names like "Test User 1" and companies like "Acme Corp".

Masked data is real customer data with PII replaced. It preserves realistic patterns, like usage volumes, event sequences, and edge cases, while stripping identifying information. The risk is that masking is hard to do completely. Residual PII can leak through in unexpected fields.

Customer-like data is synthetic data modeled on real customer behavior, with the same distributions, patterns, and edge cases, without copying any real records. It is the best of both: realistic without the exposure risk.

The privacy concern teams miss most often is using a real customer's account structure as the seed template, even with names changed. If the account hierarchy, the team size, the feature usage pattern, and the date range are all copied from a real customer, a sophisticated buyer who knows that customer can reconstruct the source. Build the seed from a statistical model of your customer base, not from a single customer's data.

The reset path that keeps bad state from sticking

Every sandbox demo session should start from the same known state. The reset path is what guarantees this: a script or API call that runs at session end, or session start as a pre flight check, and wipes any state the previous viewer created.

The reset script needs to handle demo scoped database records, session tokens, file uploads, and any async jobs the viewer triggered. If it misses one of these, the next viewer inherits broken state: a partially completed workflow, a missing record, an error that only exists because the previous session left something behind.

Keep parity with the shipped product without rebuilding the demo every release

The parity gap nobody notices until sales uses it

The structural cause of parity drift is simple: the demo is built once, the product ships weekly, and nobody owns the reconciliation. The demo becomes a second code path, maintained by whoever last touched it and drifting further from the real product with every release.

The first place parity breaks is usually navigation. A renamed menu item, a moved settings page, a new top level route: these change the product's information architecture without changing its core functionality. The demo still works, but it shows a product that no longer exists. Sales uses it anyway because rebuilding it takes time nobody has.

Prompts, diffs, and the maintenance loop

A code owned sandbox demo closes this loop. When the product ships a UI change, the agent gets a prompt: "The settings page moved from `/account/settings` to `/settings`. Update the demo layer, fix the seed navigation, and check that the reset path still covers the new route."

The diff is small because the demo renders from the same source as the product. The agent is not re recording screens or re cloning HTML. It is updating a thin configuration layer and a seed script. The result is a demo that matches the current product, maintained in the same workflow as the product itself.

This is the maintenance model PostHog describes for their own demo sandboxes: the sandbox is a governed artifact with a defined update path, not a one off recording that someone updates when they remember to.

Track engagement and reset behavior like a buyer-facing system

Which events matter for sales and PMM

The metrics that tell you whether the sandbox demo is working:

• Session starts — how many buyers opened the demo
• Feature interaction rate — which features buyers actually clicked, not just saw
• Completion rate — how many buyers reached the CTA or the end of the intended flow
• Drop off point — where buyers left, which tells you where the demo loses the thread
• CTA conversion — how many demo sessions turned into a next step, like a booked call, trial signup, or reply to follow up

For a PMM, the most useful signal is the drop off point. If 70% of buyers leave at the same screen, that screen is either confusing or irrelevant to the buyer's job. That is a demo problem, a product problem, or a targeting problem, and you cannot tell which one without the data.

What reset and parity logs tell product engineering

Reset failures and parity drift are engineering signals, not just demo annoyances. A reset that fails means the next session starts with corrupted state, and if that session is a live sales call, the AE finds out mid demo. A parity log that shows the demo is two releases behind means sales is showing buyers a product that no longer ships.

Tracking these as explicit events — reset success or failure, demo version versus product version diff — turns demo maintenance from a reactive scramble into a monitored system. When the parity gap exceeds one release, the agent gets a prompt. When resets fail more than once in a session window, the seed script gets reviewed.

Choose the sandbox demo when the alternative is a second system

Where a sandbox demo beats a traditional demo environment

Use the sandbox demo when the buyer needs something genuinely interactive, with real clicks, real state, and real data, but you do not want to maintain a full hosted environment just to show it. A traditional demo environment, like a staging instance, a dedicated tenant, or a shared sandbox server, needs infrastructure, ongoing maintenance, and someone to own it. It also tends to accumulate state: old sessions, stale data, broken workflows from previous demos that nobody cleaned up.

A repo native sandbox demo is lighter. It runs from the product codebase, seeds on demand, resets cleanly, and gets updated by the same agent workflow that maintains the product. For a solo founder or a small product team, that is the difference between a demo that stays current and a demo environment that turns into a maintenance burden.

The concrete scenario where it wins: a prospect asks to explore the product before a sales call. A walkthrough shows them a recording. A trial drops them into an empty product with no context. A sandbox demo shows them a lived in version of the product, scoped to the features that matter for their use case, with a reset path that wipes their session before the next prospect sees it.

Where it loses to a walkthrough or real trial

A guided walkthrough, like Supademo, Arcade, or a screen recording, is the right call when the demo path is linear, the product does not change often, and the buyer just needs to see the flow, not explore it. The walkthrough is faster to build, easier to distribute, and needs no infrastructure. If the buyer's question is "what does this look like?" rather than "can I actually use this?", a walkthrough answers it.

A real trial is better when the buyer needs to test the product with their own data, against their own workflow, at their own pace. The sandbox demo cannot replicate that. It is curated, not open ended. If the buyer's question is "will this work for my specific situation?", give them a trial.

The sandbox demo becomes overkill when the product is simple enough that a walkthrough communicates it fully, or when the buyer population is large enough that individualized sandbox sessions are not scalable. At that point, a well maintained interactive demo, like Supademo or Inkly, is the right tool. The sandbox demo is for the buyers who need to get their hands on something real.

Where Inkly comes in

The hard part of a sandbox demo is not building it the first time. It is keeping it current after the product ships. The demo needs to match the live product, the seed data needs to stay realistic, and the reset path needs to work reliably. All of that has to happen without turning the demo into a second system that somebody has to maintain separately from the product.

The repo native architecture this article describes solves that structurally: the demo is code that lives next to the product, updated by the same agent that updates the product. Inkly is built on that premise. The demo is not a recording in someone else's SaaS. It is code you own, authored and maintained by your coding agent (Cursor, Claude, Codex) through the same three prompt loop you already use: prompt to create, prompt to update, prompt to produce a variant for the next prospect. The tradeoff is straightforward: Inkly's MVP path is bring your own agent, so if you are not already running Cursor or Claude in your workflow, there is setup involved. But if you are, the demo lives in your repo and stays current with a prompt, not a re record.

FAQ

Q: What exactly is a sandbox demo, and how is it different from a live sandbox, free trial, or interactive demo?

A sandbox demo is a controlled interactive replica of your product, with real UI, real interactivity, and seeded data, running in an isolated environment with no connection to production. A live sandbox is a full product instance that can accumulate real state and is expensive to reset. A free trial is the real product with access limits and no curation. An interactive demo, like Supademo or Arcade, is a recorded or cloned snapshot with no real state. The sandbox demo sits between the interactive demo and the live sandbox: more interactive than a recording, more controlled than a real instance.

Q: When should a product team use a sandbox demo instead of a traditional demo environment?

Use the sandbox demo when buyers need genuine interactivity, with real clicks, real state, and realistic data, but you cannot justify the infrastructure cost of a full hosted demo environment. The sandbox demo is the right fit when the product is complex enough that a walkthrough undersells it, but a trial drops buyers into an empty product with no context. It is especially strong for high intent prospects in a sales led motion, where a curated, pre seeded environment communicates the product better than either a recording or a blank trial.

Q: How can a founder or product engineer build a sandbox demo without adding a separate SaaS dependency?

Build it as a repo native layer: a demo mode flag in the product codebase, a seed script that populates realistic data, a reset path that wipes session state, and an analytics hook on demo specific events. The demo renders from the same source as the product and gets updated by the same agent workflow. That keeps the demo current without a separate tool, a separate deployment, or a separate maintenance burden.

Q: What data, workflows, and screens should be included so the demo feels real but stays safe?

Include enough data that the buyer recognizes their own workflow: two or three user roles, one or two realistic organizations, recent activity records that make the dashboard feel active, and any workflow state the product's key features operate on. Use synthetic data generated from a statistical model of your customer base, not masked real customer data, which carries residual PII risk. Scope the demo to the features that matter for the buyer's use case. A demo with too many screens dilutes the story.

Q: How do sales and presales teams use sandbox demos to improve live calls and follow up?

In a live call, the sandbox demo lets the AE hand control to the prospect: "click around, show me what you'd do first," without risking a broken flow or a production data leak. The seeded data gives the prospect context without requiring them to set anything up. In follow up, a sandbox demo link sent after the call lets the prospect explore independently, and the engagement analytics, like which features they clicked, where they dropped off, and whether they hit the CTA, give the AE a signal on what to address in the next conversation.

Conclusion

Go back to those two tabs, the sandbox demo and the live product. If they still match, the architecture is doing its job. If they don't, the gap is not a demo problem. It is an ownership problem. The demo is not living next to the code that ships.

This week: pick one demo flow and audit it against the current product. If the demo is a SaaS locked recording, ask whether it belongs in your repo instead. If it is already code you own, check whether the seed data, reset path, and analytics hook are all in place. The architecture is not complicated, but it has to be deliberate, or the demo drifts the moment the product ships.