Real app, real data, real reactions

Build me a realistic prototype of my product as a small web app (Vite + React, plus a small server if it reads live data, unless I name another stack). Treat it as a research rig, not a demo: it should look, move and behave like my real app, with real data and real logic behind every screen, so participants use it the way they use the product and stop performing for me.

Before you write any code, ask me the six questions below, in order, one at a time, and wait for each answer. Skip any I have already answered in my message or in what I attached, and tell me what you took from it instead. Where I cannot answer one, tell me what you will assume, then carry on.

1. What am I trying to learn? The research question, who the participants are, the tasks I will give them, and how sessions will run: in person on my device, remote on the participant's own device, or unmoderated. If I am unsure, assume a first-time user doing the product's most common task, in person.

2. What is my product, who uses it, and what are its key flows? Every screen a user moves through on the journeys that matter, including what sits either side of the happy path. A shopping app, for example, runs feed, category, product, cart, payment, order placed, past orders. Also the platform (phone app, mobile web, desktop), the language or languages, the currency, and date and number formats. If I cannot list the screens, model the standard flow for a product like mine. If I do not name the platform, assume a phone, in my language and currency.

3. Where does my data come from? Which of my services or APIs the prototype may read from and with what access (a read-only key, a read replica, a proxy my engineers run), and which tables and fields each value on screen comes from. It reads through those, never by querying production databases directly. Also tell me who on my team (the data owner, privacy or legal) has approved using this data for research. Values can come from my services where I have access and approval, and from a synthetic data layer where I do not, in the same app. That layer is shaped like my real tables (same entities, fields, types and relationships), so a source can be pointed at the real one later without touching a screen. If no one has approved real data yet, build it all on the synthetic layer and leave the real source as a switch I turn on once they do. If I cannot name my tables or fields, infer a schema from my screens.

4. What rules does my product run on? How it works out every value it computes: prices, totals, fees, eligibility, limits, dates and statuses. If I do not know a rule, say so; you will use the most common convention for products like mine and mark it as an assumption.

5. What does my product look like, and how does it move? Type scale, spacing, radii, colours, components, transitions and gestures, from my design system, my tokens or screenshots of the live app. If I have none of these, ask for a link to the live app or a screen recording and match what you can see. If I truly have nothing, build on a plain neutral system, say that this is an assumption, and expect participants to notice. Never present a generic kit as my product's look.

6. What do I want to test? The new feature, content row, badge or variant, and where in the product it appears. If there is nothing new yet, build the current product faithfully and leave a flag ready for it.

When you have every answer, play the plan back to me in one message, before any code: the screen list and routes, which screens are load-bearing for my research question, where each value on screen comes from (my service, or the synthetic layer, with the schema you inferred if I could not name one), the rules you will compute, the flags and switches you will add, and every assumption you are making. Wait for me to say go.

One rule overrides everything that follows: real data about real people needs their permission and my organisation's approval. If keeping to it costs fidelity, keep to it and tell me what it cost.

a. Show a participant only their own data, read-only, and only after they have consented. Their account loads only when they sign in themselves or give me their own ID in the session; never let anyone browse, search or pick accounts. If a participant has no account or does not consent, run the session on a synthetic profile, never on another real person's data. Fetch only the fields the screens show.

b. The app opens on synthetic data by default, and real data loads only in a session I start. Put any hosted URL that can reach real data behind a password or an allowlist, so a link sent to a stakeholder never shows a participant's data.

c. Call only read endpoints with no side effects. Never write back to production, and never call anything that charges, places an order, sends a notification or message, or fires events into my product's analytics or recommendations. Anything a session changes lives in the prototype's own store, and the wipe after a session clears it, including anything stored on the participant's device.

d. Keys live on the small server, which is the only thing that calls my services. The browser talks only to that server, no key goes in a client-side environment variable, and nothing personal is logged.

e. If I record sessions, remind me the recording will show the participant's own data, so their consent has to cover it and the recording needs the same care as the data.

Then build it to these rules, in order of importance:

1. It must not feel like a prototype. Every screen a participant can reach must exist. No dead links, no "coming soon", no jump back to the home screen because I did not build that page. If a tap has nowhere to go, build the somewhere.

2. Use routes, not screens-as-slides: one route per screen in the flows I gave you. Back must work. Refresh must work. Deep links must work.

3. Every value comes from a table. No name, price, count, date or status is typed into a screen; screens read through one data module from my services or the synthetic layer, so switching a source changes nothing on screen. Vary synthetic data the way real data varies, in my users' language, currency and places: a few outliers, some empty states, a name long enough to wrap.

4. Put real logic behind the values. Everything my product computes is computed from the data by the rules I gave you, never drawn as a fixed screen. Where a rule is still unknown, use the most common convention for products like mine, mark it as an assumption in the code and list it at the end. Never present an invented rule as mine.

5. Every flow I gave you completes end to end, including what the real product shows afterwards: the record, its status, and where to find it again. If my product takes payment, it runs on dummy instruments only. Give me a switch to make any step that can fail in my product fail (a payment, a network call, an item running out, a verification code), so I can test the recovery path too.

6. Match my real product's type scale, spacing, radii, components and motion. A prototype that is nearly right in layout but wrong in type reads as fake within seconds.

7. Build for the platform I named. On a phone: 375px viewport, thumb-reachable controls, real scroll momentum, no hover-only affordances.

8. Put the things I want to test behind a flag, so I can turn a new feature, row, badge or surface on for one session and off for the next without a rebuild.

When it runs, give me: the command to run it; a URL I can send to a moderator or participant, and how to put it there; if it reads live data, how to load a consenting participant's data and wipe it afterwards, and if it is synthetic, how to reseed it; the list of flags and switches; and every value or rule that still rests on an assumption. Then show me that no key or personal field reaches the browser or the logs, and that the wipe leaves nothing behind, so I can check all of it before the first session.