First-release review
Your AI-built app works in the demo. What should you test before release?
UxerProof Editorial · · 3 min read
A demo usually starts with favorable conditions. The presenter knows the navigation, the account already exists, and the sample record has the right fields. That makes the demo useful for explaining a product. It also leaves important questions unanswered about what happens when someone starts from scratch.
Before releasing an AI-built app, test the transition from a clean starting point to a useful, persistent result. The goal is not to penalize the development method. It is to verify the experience that the release promises.
Start where a new customer starts
Use a fresh, authorized test account with the intended permissions. Avoid a developer session that silently skips verification, onboarding or workspace selection. Record the environment and release version so another reviewer can repeat the same exercise.
Choose one outcome. In an illustrative project app, that might be creating a project, adding a task and returning to it after signing out. “Open the dashboard” is too early a finish line if the product's value begins with saved work.
Write down every dependency the task needs. If the journey requires an administrator, an integration or an email, include that dependency in the test plan. Do not use a prepared account to hide a setup step customers must complete themselves.
Inspect the places a polished demo skips
Try the journey with no existing records. Submit one invalid field. Leave and return before the task is finished. Where safe and supported, inspect an expired session or an unavailable dependency.
Ask specific questions:
- Does the empty screen offer an achievable next action?
- Does an error explain what the person can correct?
- Is work preserved where the interface promises it will be?
- Does the saved result survive a reload?
- Can the intended role find that result again?
Use synthetic data and controlled inboxes. A release review should not accidentally invite customers, charge a card or modify live business records.
Separate product defects from test limitations
An unavailable test email service can block a valid run without proving the signup interface is broken. Equally, a success message does not prove an item persisted. Record what happened and what remains unknown.
For each issue, keep the starting state, attempted action, observed response and evidence reference. Give confirmed defects an owner and a repair check. Keep blocked or unassessed steps visible rather than folding them into a reassuring overall label.
Make a narrow release decision
A successful task provides evidence about that task under its recorded conditions. It does not certify the whole application. Security, data isolation, recovery, accessibility and commercial operations may need separate checks.
End the review with a plain statement: what worked, what did not, what was not assessed and who accepts any remaining limitation. That is a more useful handoff than a screenshot of a green build.
Next step: Use the Golden Journey Test Contract to define the first release-critical task before execution.
Put the evidence structure to work
Inspect UxerProof's fictional sample report, or use the free readiness check to prepare your next journey. External Circuit execution is not yet activated; see current launch status for availability.