How to create a demo environment from your product repo

Open your current demo environment in one tab. Open your live product in another. Count the things that do not match.

The quickest way to build a demo environment is to base it on your product repo, not on a separate SaaS demo tool, not on a cloned staging database you have to babysit, and not on a screen recording of last sprint's UI. When the demo config, seed data, and app code live together, the demo changes the same way the product does: with a commit.

Here's how to build it.

What a repo-first demo environment actually is

The app, demo config, and seed data in one repo

A repo-first demo environment is not a second app. It's a thin layer next to your existing code: a `demo/` folder (or something like it) with a config file, a seed data file, and a reset script. The app reads the config at startup and loads the seed data instead of production records. Your repo tree might look like this:

The setup lives in version control. Rename a nav item, and the demo gets the rename in the same PR. Add a feature, and the config exposes it on the next deploy. No separate tool. No manual sync.

Why the demo should be a thin slice, not a clone

A full production clone breaks in three ways: it's expensive to keep current, it drags in complexity that confuses prospects, and it turns into a maintenance job nobody owns. The goal is not perfect fidelity to production. It's fidelity to the story you're trying to tell on a call.

A narrow slice, one workflow, one persona, one outcome, is easier to seed, faster to reset, and believable enough to do the job. PostHog's guide on multiple environments makes the same point for feature flags: isolate the surface area you need. Do not clone everything.

Pick the smallest demo environment that still tells the story

Choose one real workflow and cut everything else

Before writing a line of seed data, name the one thing the demo has to prove. Not "the product," not "all the features" — one workflow a specific persona completes to get one outcome. A project management tool might demo "create a task, assign it, mark it done." That's enough. Everything else just makes the demo harder to maintain.

Pick the workflow that matches your highest-intent buyer. Build the seed data around that workflow. Do not add a second persona until the first one works cleanly.

Leave out the junk that makes the demo brittle

Four things reliably break demo environments:

• Admin paths. Settings screens, billing pages, and permission matrices add complexity and pull attention away from the workflow.
• Edge-case data. A user with 10,000 records, a project with 47 nested subtasks, a null-state screen — none of these help the story.
• Full production permissions. Demo users should have exactly the access the workflow needs. Broader access exposes unfinished UI.
• Noisy data. Fifty fake companies with random names, a hundred events with no pattern — the demo should look like something a real person might use, not a database test.

What "realistic" means for builders, not marketers

Realistic means the data tells a coherent story, not that it's huge. Three well-named fake accounts, five representative tasks, one completed workflow — that is usually enough. The prospect needs to see themselves in the demo, not admire the size of the dataset. A believable name like "Acme Corp" and a project called "Q3 Launch" does more work than a hundred random records.

Separate demo data from production data before anything else

This is the step most founders skip and later regret.

Give the demo its own database, bucket, or namespace

The safest default: the demo runs against its own database or namespace, completely separate from production. Not a flag on a shared table. Not an `is_demo: true` column. A separate boundary.

That removes the risk of demo resets touching production records, and it removes the temptation to "just use staging." Staging drifts. Demo environments need to be stable and resettable on demand.

Seed believable records without copying real customer data

Copying real customer data into a demo environment is a privacy risk and a GDPR problem. Generate fake but plausible records instead: a company called "Meridian Health," a user named "Alex Rivera," a project called "Website Redesign." The Stripe AI agents benchmark makes the same point about test environments — a well-defined, replayable environment with representative data is more useful than a production mirror.

A seed file that creates five accounts, ten tasks, and two completed workflows is enough to make the demo feel inhabited. Keep the seed file in the repo beside the app code.

Reset the demo without hand-cleaning tables

Manual cleanup is why demo environments go stale. Someone runs a demo, leaves the data in a weird state, and the next demo shows the wrong thing. The fix is a reset script that truncates the demo tables and reloads the seed file in one command:

Run this before every demo call and the leftover-data problem goes away. The script lives in the repo. Not in a Notion doc. Not in Slack. Not in someone's head.

Use code to create and refresh the demo environment faster

Build the first version from the same primitives as the app

Do not invent a second stack for the demo. Reuse the app's existing feature flags, environment variables, and seed tooling. If the app already has a `NODE_ENV=test` path that loads fixtures, the demo environment is a variation of that path, not a new system. The Vercel platform API demo pattern shows this directly: configure via `.env.local`, point at a demo-specific config, and the same app code serves the demo.

Let your agent update the demo when the product changes

This is where a repo-first demo environment earns its keep. When the product UI changes, the fix is a normal code change, not a re-record in a SaaS editor. Point Cursor, Claude, or Codex at the diff and the demo config:

The agent edits the config, the seed file, and any demo-specific copy in one pass. The demo stays current before the PR merges. That is the repo-first maintenance loop. It does not need a separate tool, a separate owner, or a separate process.

What breaks when the UI changes and the demo is still code

The failure mode founders worry about is simple: a UI change breaks the demo flow. With a screenshot-based tool, a changed button label or renamed nav item means re-recording every affected screen. With a repo-first demo, the same change is a config update or a seed data edit. The fix is proportional to the change. A renamed field is a one-line edit, not a full re-record session.

The demo cannot go stale in a separate SaaS editor if it was never in a separate SaaS editor.

Keep the demo environment maintainable for a solo founder

Put reset, seed, and update steps in the repo itself

A README in `demo/` that documents three commands — start, seed, reset — is the whole maintenance contract. If the instructions live in Notion, they drift. If they live in Slack, they disappear. Beside the code, they get updated when the code gets updated.

Build the personalization layer last

Per-buyer names, logos, and account-specific data should sit in a separate config layer on top of the stable base demo, not baked into every screen. When you need to personalize for a specific prospect, you change the config file, not the seed data. That keeps the base demo stable and turns personalization into a five-minute task instead of a rebuild.

Decide what gets automated before the demo ships

The minimum viable checklist for a solo founder shipping a repo-first demo environment:

• Reset command — one script, runs in under a minute
• Seed data — checked into the repo, generates believable records
• Staging URL — a stable URL that always shows the demo state
• Update path — documented in `demo/README.md`, executable by an agent

That's the whole system. Knowing how to create a demo environment that stays current does not require a fancy sandbox. It requires a clear, automatable loop that does not depend on heroics.

Where Inkly comes in

The structural problem a repo-first demo environment solves is ownership: the demo lives beside the product, so updates are normal code changes. But building the demo itself — the polished, clickable, branded screens a prospect actually sees — still takes time if you're starting from scratch.

Inkly is built on the same premise. Your demo is code you own, created via a Chrome-extension capture or a direct agent prompt, and maintained through the same three-prompt loop the rest of this article describes: prompt to create, prompt to update, prompt to produce a variant for the next customer. The demo lives in your repo, next to your product. When the UI changes, you re-prompt. No re-record. No SaaS editor. No separate maintenance track.

The honest tradeoff: Inkly's MVP path is bring-your-own-agent (Cursor, Claude, Codex). If you do not have a coding agent set up yet, the loop needs that first. But if you're already working in a repo and prompting your way through product changes, the demo becomes code you maintain the same way you maintain the app.

FAQ

Q: What is the fastest way to create a demo environment for a product that changes frequently?

Build it repo-first: the app code, a demo config file, and a seed data file in the same repository. When the product changes, the demo config changes in the same PR. No separate tool. No manual sync. The demo stays current because it's maintained the same way the app is maintained.

Q: How do you keep a demo environment current without manually rebuilding it every release?

Keep the demo logic in the repo and update it with your coding agent (Cursor, Claude, or Codex) alongside each product change. When a PR renames a nav item or adds a feature, the agent updates the demo config and seed data in the same pass. Manual rebuilds happen when the demo lives outside the repo. Move it in, and that problem goes away.

Q: What should a demo environment include so a founder can show the product clearly without too much setup?

One workflow, realistic seed data for that workflow, a reset script, and a stable URL. Five well-named fake accounts and ten representative records are enough to make the demo feel inhabited. Everything else adds maintenance cost without helping the story.

Q: How can a product engineer update the demo environment from code as the app evolves?

Change the app, update the demo config and seed data to match, run the reset script locally to verify, and commit the update like any other code change. If the demo lives in `demo/config.json` and `demo/seed.sql` beside the app, the update path is the same as any other file in the repo.

Q: How do you make a demo environment feel realistic without turning it into a maintenance burden?

Realism comes from a few specific, representative tasks and believable data shapes, not from production volume or every edge case. Three coherent fake accounts and one completed workflow feel more real than fifty random records. Keep the surface area small and the reset path automated, and the demo stays credible without becoming a second product to maintain.

Conclusion

The demo tab and the live app should tell the same story. They will not if the demo lives somewhere separate from the code that drives the product.

Build the first repo-first slice this week: a `demo/` folder, a seed file, a reset script, and a README with three commands. The next time the app changes, update the demo in the same commit. That is the whole loop, and it is the only one that does not require heroics to maintain.