1 / 7
Can one real user complete the paid or promised flow?
Not the demo path. A fresh user, clean browser, real account state, real recovery path.
No, only the demo path works
Seeded data or admin help is still needed.
Mostly, but one handoff is vague
Something still depends on luck or manual correction.
Yes, one flow is proven
Fresh user, expected outcome, and final state are written down.
I have not tested it cleanly
The app feels close, but the evidence is not captured.
2 / 7
If money moves, is the final business state trusted?
Checkout success is not proof. The app needs durable entitlement, retry safety, cancellation, and recovery.
No payment proof yet
Success page or local UI state does most of the work.
Happy path works
Retries, refunds, failed renewals, or cancellation are not proven.
Webhook-backed final state is proven
Duplicate, delayed, failed, refunded, and canceled states are handled.
No payment in this app
Money state is not part of the launch-critical flow.
3 / 7
Can one user, org, or role see another user's private state?
The UI hiding data is not enough. Test direct rows, files, server routes, and team/org boundaries.
I do not know
No Alice/Bob negative test exists.
Basic RLS exists
But storage, server routes, or role transitions are not checked.
Negative cases are proven
Alice/Bob and org A/org B are denied across the risky paths.
No private data yet
The launch flow does not expose user-specific or tenant data.
4 / 7
Does the app show what the AI output is allowed to know?
Users need evidence boundaries: source state, uncertainty, private context, refusal, and escalation.
The answer just appears
No source, uncertainty, or missing-evidence state is visible.
Some labels exist
But weak retrieval, prompt injection, or private context boundaries are not tested.
Output boundaries are explicit
The app handles missing sources, uncertainty, injection attempts, and human review.
No AI output shown to users
The risky launch flow is not an AI answer/recommendation flow.
5 / 7
When a user gets stuck, can support inspect the truth?
“I paid but I am locked out” should have evidence, not vibes.
No support trail
There is no way to inspect the user's authoritative state.
Logs exist somewhere
But payment, account, entitlement, and content state are scattered.
One-user recovery is inspectable
There is a support view or runbook for the launch-critical states.
Manual but documented
Not polished, but the exact inspection steps are written.
6 / 7
Can a buyer understand the promise in one sentence?
Broad apps are hard to sell and hard to prove. Narrow paid outcomes are easier.
No, it still sounds like a platform
The promise has too many audiences or outcomes.
Almost
Buyer and pain are clear, but proof or scope is vague.
Yes, one buyer and one outcome
The offer is narrow enough to pre-sell or deliver manually.
I need help narrowing it
The app works, but the offer is mushy.
7 / 7
Do you have one written final-state test?
The smallest useful proof: user starts, flow completes, trusted state changes, UI agrees, recovery is possible.
No written test
The app “seems fine” but the proof is not captured.
Some checks are written
Happy path exists, but negative/failure state is missing.
Yes, one final-state test exists
The critical flow has proof, negative case, and expected state.
It is in my head
Useful intuition, but not launch evidence yet.