Simulated vs real features: an invitation screen with no email service
Illustration, not client work
An invitation flow shows "Invitation sent", but no email service is connected.
If the research question was whether a team owner understands invitations, the simulation may have done its job.
The build brief still has to cover delivery, expired links, people who already have an account, resend rules and what happens when delivery fails. With that written down, a developer can size the real work, beyond what the success screen shows.
An MVP readiness checklist for founders and product teams
It suits founders with an MVP prototype, product managers about to hand a prototype to a development team, and designers whose prototype has done its research job. It works the same for a clickable design, a coded prototype or an app made with an AI app builder.
If your prototype was vibe-coded, the checklist shows which parts are real before anyone prices the build. The sorting matters most there, because a generated app can look finished while saving nothing.
AI app builders keep getting better at looking finished, and some now connect real databases and payments in a few clicks. That makes the sort more valuable: the checklist separates a real saved order from a convincing one, before anyone budgets the build.
How to use the checklist: start with what the prototype was for
Was it built to test demand, whether people understand the task, a tricky interaction or whether the thing can be built at all? Judge it against that purpose first. A prototype can answer its research question and leave saving, permissions and day-to-day support for later, on purpose.
Open the prototype and follow one workflow from start to finish, using sample data you are allowed to work with. If you can't tell how something works, mark it unknown and ask whoever built it. A guess makes a misleading brief.
Prototype checklist: seven things to check in one workflow
| Check | Questions for the brief |
|---|---|
| Records and saving | What gets saved, where, and what survives a refresh or a new session? |
| Roles and access | Who should see and change the record? Where are those rules enforced? |
| State and recovery | What happens during a delay, a failure, a repeat submission or two people editing at once? |
| Dependencies | Which outside services, payments, messages or AI responses are real, mocked or still to be chosen? |
| Product decisions | Which names, defaults, rules and states were chosen on purpose? |
| Usability and access | Can the intended person finish the task with realistic content, a narrow screen and a keyboard? |
| Evidence | What did participants do, what was observed and what is still untested? |
Mark each item "demonstrated", "simulated", "unknown" or "not applicable". "Demonstrated" describes what you saw in this example; going live takes further checks. "Unknown" marks behaviour the prototype hasn't shown yet.
For each unknown, note what it is about (saving, permissions, recovery, an outside service or another product rule) and the decision or build work that would answer it.
Prototype build brief template: sort your answers into three lists
Group what you found into three lists: decisions to make, research to run and build work to scope. Give each item an owner and a check that would close it. Bring engineering in early, because some decisions only become clear once an engineer has looked.
Give code quality, security, infrastructure and data protection each a specialist review and a named owner in the brief. GOV.UK's prototyping guidance explains why code written for a prototype may need rework before it goes live.
Prototype to developer handover: take the brief into the build
Download the brief and share it with the prototype link. It tells a developer which behaviour to keep, which assumptions to question and what still needs proving.
For a review of one workflow by a senior designer, with an engineer reading the code if you share it, see the Prototype Readiness Review. If the bigger question is whether the idea works for users, start with Prototyping & Usability Testing.
Prototype readiness checklist FAQs
Is there a checklist to see what our prototype really proves?
This checklist does that, free. Follow one workflow and mark each of seven areas "demonstrated", "simulated", "unknown" or "not applicable". Judge the result first against what the prototype was built to test.
How do I hand an AI-built prototype to developers?
Share the prototype link with a brief that says which behaviour is real, which is simulated and what is still unknown. Mark AI responses and outside services as real, mocked or still to be chosen. Our article on taking a vibe-coded app to production covers what comes next.
What should a build brief from a prototype include?
Three lists: decisions to make, research to run and build work to scope, each item with an owner and a check that would close it. Add the specialist reviews the build needs, such as code quality, security and data protection, each with an owner.
How do we tell simulated features from real ones?
Test what survives. Refresh the page, start a new session, sign in as a second user and let something fail: a real feature keeps its record and handles the failure. If you can't tell, ask whoever built it and mark it unknown until they answer.
When does a prototype need a specialist review?
When the brief holds more unknowns than answers, or before you commit a build budget to it. In our Prototype Readiness Review, a senior designer goes through one workflow, and an engineer can read the code when you share it.