# How do you swap real data for mock data in a demo built with AI?

- URL: https://getroomi.com/guides/how-to-use-mock-data-in-an-ai-built-demo
- Updated: 2026-10-12

Replace every call to a real system with data that lives inside the demo. That can be a file of sample records, a mock API in the browser, or a small database seeded on start. Shape it like the client’s world, but invent every name and figure. Then it is safe to send, and every viewer can change anything.

This guide covers four ways to give a demo its own data, from the simplest up, and the words to ask your AI agent for each. Then how to make the data convincing, what to do with features that call an AI model, and how to check nothing real is left. [Static demos](https://getroomi.com/docs/static) and [container demos](https://getroomi.com/docs/containers) explain the two kinds of demo it applies to.

## Why does a demo need mock data?

Because every viewer gets a copy of whatever is in it. A real record in a demo is a real record sent to every client who opens it. A live backend left connected means a demo can reach real systems. And on Roomi, a container demo has no internet, so it could not reach a live system anyway.

There is a selling reason too. On mock data, a viewer can press anything, change anything and break nothing. That is what makes a client try it rather than watch it.

An app copied out of a builder can keep its live wiring. Lovable’s hosting guide says an app deployed to another host can keep using its built-in Cloud backend. The backend’s address and publishable key are built into the browser code. A Lovable app on Roomi runs on sample data, never on its live Lovable Cloud backend. Every demo runs on mock data, and a container demo has no internet to reach one. Sharing a Lovable app with a client covers that route from start to finish.

## What are the ways to give a demo its own data?

There are four, and most demos need only the first or second. Sample files hold lists and tables. Data in memory gives a small tool something to change. A mock API answers an app that was written to call one. A seeded database suits a demo with real logic, and runs as a container demo.

| Approach | Where the data lives | Good for | On Roomi | What it takes |
|---|---|---|---|---|
| Sample files | JSON files in the build | Lists, tables and dashboards | A static demo, on every plan | Ask your agent to read each list from a file |
| Data in memory | The page itself, reset when it reloads | Small tools and calculators | A static demo, on every plan | A few lines of code |
| A mock API in the browser | A mock service worker that answers the app’s requests | Apps written to call an API | A static demo, on every plan | A library, and a handler for each route |
| A seeded database | A SQLite file in the container, seeded on every start | Apps with real logic and saved changes | A container demo, Pro and up | A seed script and a Dockerfile |

Try them in this order, and stop at the first that does the job:

1. **Sample files** — the simplest. Every list the app fetched now comes from a file in the build, so the demo needs no server at all.
2. **Data in memory** — for a tool the viewer changes as they go. Changes last until the page reloads, which is a reset for free.
3. **A mock API** — for an app that is written around calls to a server. Mock Service Worker is a library that answers an app’s network requests with mock responses, in the browser and in Node.js. Its docs name a live demo among its uses. The app keeps its code, and the answers come from inside the demo.
4. **A seeded database** — for a demo whose logic is the point: orders that move through stages, totals that add up. Each private link gets its own copy, which starts from the seed every time.

## Ask your AI agent to do it

You do not need to write any of this yourself. Ask the agent that built the app. If you have run `roomi init`, the `PITCH.md` it wrote already tells your agent the rules: mock data only, no secrets. In a Claude chat, the connector gives Claude the same rules before it deploys.

For sample files:

```text
Make a demo version of this app that never calls the real backend. Move every list it fetches into JSON files under demo-data, with invented names and figures shaped like a regional accountancy firm’s.
```

For a mock API:

```text
Keep the app's API calls as they are, but answer them in the browser with Mock Service Worker, using the JSON files in demo-data. Nothing should reach a real server.
```

For a seeded database, in a container demo:

```text
Make this a container demo for Roomi, keeping to the build contract at https://getroomi.com/docs/containers. Seed a SQLite file in /app on every start, and add a reset route that puts it back.
```

Read what it changed before you deploy. [Build with your AI agent](https://getroomi.com/docs/ai-agents) shows what `roomi init` leaves for your agent.

## How do you make mock data convincing?

Shape it like the client’s world, then invent every detail. Use their industry’s words, their kind of customers, figures of the right size, and a few rough edges a real business has. A list of “Test User 1” tells a client nothing. Twelve believable invented clients tell them it was made for them.

- **Their kind of records.** A dental practice has appointments and recalls; a haulier has drops and depots. Ask your agent for both the shape and the names.
- **Realistic sizes.** A few dozen records feels real; five feels empty. Keep the figures plausible for a business of their size.
- **Names that are clearly made up.** A real-looking address or company name invites the question of whose it is. On a community listing, Roomi’s pre-flight scan flags names that might identify a real business, as a guess.
- **Their logo and words only with permission.** In a private room sent to them, a client’s own branding can help. Never put it on a public listing.

If the demo has a tour, set each step up so it works on its own. A viewer can start at any step, so a step that needs an order to exist should make one first. [Writing the tour](https://getroomi.com/docs/story) shows how.

## What about features that call an AI model?

Swap them for canned answers. A container demo has no internet, so a call to a model at run time fails in the room. A static demo would need a live key in the browser to make one, which is a key published. Record a few good answers to the questions the tour asks, and play those back.

If the demo began as a Claude artifact, its Claude-powered parts have a further catch. An artifact that calls Claude costs its maker nothing. Each person using it signs in with their own Claude account, and their use counts against their own plan. For people invited from outside your organisation, the parts of a Claude artifact that use Claude or your connectors do not work. Canned answers work for everyone, with or without a Claude account.

## Check nothing real is left

1. **Rehearse the deploy.** `roomi deploy` scans the project and the build for secrets, and stops on a finding. From a chat, the connector flags files that look like they hold a live key.
2. **Ask your agent what the app calls.** “List every outside address this app calls when it runs.” The right answer is none.
3. **Search for the real names.** Your client’s, your own customers’, and any email address that is not obviously invented.
4. **Open it signed out.** A private window, signed out of everything, shows what a client sees.

A demo that passes all four is ready for its link. [Is it safe to send a client a link?](https://getroomi.com/guides/is-it-safe-to-send-a-client-an-ai-built-app) has the rest of the checks.

## Questions people ask

### Will every viewer see the same data?

Every viewer starts from the same mock data. On a static demo, what they change stays in their own browser. A container demo gives each private link a fresh copy of its own, so one viewer’s changes never reach another.

### Can a viewer reset the demo?

On a container demo, yes, if you give it a reset route. The room’s Reset the demo button calls it, and that viewer’s copy goes back to its seed. Each copy also starts from the seed every time it starts.

### Does Roomi make the mock data for me?

No. Your AI agent writes it with the demo, keeping to the rules `roomi init` leaves in `PITCH.md`, or that the connector gives Claude in a chat. Roomi then scans the result for secrets before anything goes live.

### Can I use a client’s real data if they agree?

No. Every Roomi demo runs on mock data, and every room tells its viewers so. Make sample data shaped like theirs instead, and say in the tour that the figures are invented.

### Can I put the client’s logo and wording in the demo?

Only with their permission, and never on a public listing. In a private room sent to them, their logo can make the demo feel like theirs. On the community, anyone can open it, so it would tell strangers whom you are pitching.

## Sources

- Lovable: [docs.lovable.dev/tips-tricks/external-deployment-hosting](https://docs.lovable.dev/tips-tricks/external-deployment-hosting), checked 12 October 2026

- Mock Service Worker: [mswjs.io/docs/](https://mswjs.io/docs/), checked 12 October 2026

- Anthropic: [support.claude.com/en/articles/17153992-what-are-artifacts-and-how-do-i-use-them](https://support.claude.com/en/articles/17153992-what-are-artifacts-and-how-do-i-use-them), checked 12 October 2026

- Anthropic: [support.claude.com/en/articles/9547008-publishing-and-sharing-artifacts](https://support.claude.com/en/articles/9547008-publishing-and-sharing-artifacts), checked 12 October 2026

## About the author

**[Kaz Kato](https://getroomi.com/about)**, Co-founder & CTO, Roomi. Kaz co-founded Roomi with Tesh, whom he has built with since 2017: two startups that failed, one venture studio that didn’t, and an exit.

## Related guides

- [Is it safe to send a client a link to an app you built with AI? A checklist](https://getroomi.com/guides/is-it-safe-to-send-a-client-an-ai-built-app)

- [I built a prototype with AI. How do I make it real?](https://getroomi.com/guides/i-built-a-prototype-with-ai-how-do-i-make-it-real)