The short answer
Yes. Treat an AI-built MVP as a testable prototype: define a narrow task and its saved data, approve the plan, then run the complete journey before showing it. Keep technical review separate from your own test.
Build a journey you can test
- Stage
Scope
Your next moveDefine the journey
What must be clearCan you name the intended user, essential actions, visible result, saved data and excluded features? Narrow the request if not.
- Stage
Plan
Your next moveReview before edits
What must be clearCan you explain how the proposed build delivers that journey? Resolve missing decisions before approving changes.
- Stage
Build
Your next moveFix observed mismatches
What must be clearDoes the draft match the specified actions and data? Record expected and observed behavior before requesting a focused fix.
- Stage
Test
Your next moveRun the complete journey
What must be clearCan you complete the task and reopen saved information? If accounts hold private records, check what each user can access.
Your MVP test card
Intended user and task: [who, doing what] Start and visible result: [first action, expected end state] Essential actions: [what the user must do] Saved data and access: [fields, who may see them] Excluded features: [what to defer] Approved plan: [what the agent will build] Observed behavior and fix: [what happened, what needs changing] Decision and limitations: [show prototype, repair or seek technical review]
Show prototype
If the journey passes your checks, invite intended users to try it and state what remains unverified.
Repair
If the journey fails or records appear under the wrong account, fix and retest before sharing.
Seek review
Before relying on sensitive data handling or wider use, obtain technical review beyond your own journey test.
Detailed reasoning and examplesThe full playbook, source comparisons and related questions
Use this when
Use this if you can describe a specific task and inspect the resulting app, but cannot assess its code yourself.
You’ll leave with
Produce an MVP test card containing the journey, build plan, observed failures and a decision to show, repair or seek review.
Your playbook
Bound the user journey
- Do
Open the MVP test card. Specify who will use the app, the task from first action to visible result, what must be saved and what can wait. If building for someone else, distinguish their stated problem from features you merely imagine they want.
- Make
A bounded journey, saved-data fields and excluded features on the test card.
- Check
If you cannot describe what the user does and sees at the end, narrow the journey before building.
Why this step is in the plan
Approve a plan before edits
- Do
Give the agent the test card and request a plan without edits. Ask it to flag missing decisions. For an existing app, ask it to inspect the project first. Remove unexplained features and approve only a plan you can relate to the journey.
- Make
An approved build plan and resolved questions on the test card.
- Check
If the plan contradicts the journey or overlooks existing work, request a revision before allowing edits.
Why this step is in the plan
Build and repair what you can observe
- Do
Authorize the approved build. Open the draft and compare its actions and saved fields with the test card. Record each mismatch as expected versus observed behavior, then ask for a focused fix rather than another feature.
- Make
A draft app and a mismatch log on the test card.
- Check
If a change fails to fix the recorded mismatch or disrupts the journey, revise or undo it before expanding scope.
Preview the template
Expected: [behavior from test card] Observed: [what happened] Please inspect the relevant work and propose a focused fix without adding unrelated features. Tell me what changed so I can retest.
Why this step is in the plan
Test the journey and record access
- Do
Use the app from the first action to the expected result. Save and reopen information, recording expected and observed behavior. If it has accounts with private records, test with different accounts and check which records each can access.
- Make
Journey results and any data or access failures on the test card.
- Check
If the journey fails or an account shows another user's records, stop sharing, repair and retest.
Why this step is in the plan
Frederik says he tests AI-built Unity games by playing them because he cannot review their code.8 Luke Byrne's client-portal demonstration exposed a different issue: the first render had no configured data source, and the portal needed record filters matching the signed-in user's email.3
Choose what is ready to show
- Do
Mark the test card show prototype, repair or seek technical review. If the journey passes, invite intended users to try it and disclose unverified parts. Seek technical review before depending on sensitive records or broader use.
- Make
A show, repair or review decision with known limitations on the test card.
- Check
If you cannot identify what passed and what remains unverified, keep the app labeled as a prototype.
Why this step is in the plan
Andrew Chen says AI may make a prototype easier for a non-technical founder to build, while leaving a gap between a demo and a reliable product that scales.2 Tech With Lucy advises testing each smaller feature before moving to the next and flags security as a concern.9
When this works
- Choose this route when the initial experience is bounded and you can personally test whether its intended task works.
When to avoid
- Do not treat a convincing screen or a successful personal test as sufficient review for sensitive records or wider deployment.
Compare the real examples
What 1 source did and reported Explore examples ↓
- YouTube
Luke Byrne
In his client-portal demonstration, connected prepared records after the first render lacked a data source, then specified a client-email filter for the signed-in user.