A demo shows that an idea can work along a particular path. It can help you explain the product and learn whether the workflow makes sense. Before customers rely on it, we also need to understand what happens with different users, real data and interruptions.
That applies whether the prototype came from a template, an AI tool, an internal team or a previous developer. I would assess what is already useful, identify the gaps and plan the work around the risks that matter for this product.
Write down what is real and what is simulated
A prototype might show example records, simulate a payment or assume every request succeeds. List those assumptions. A screen that displays a successful booking may still need availability rules, a payment connection and a reliable record of the reservation.
Keep the useful parts of the demo. The review should explain what can stay, what needs changing and what has not yet been verified. You cannot tell which is which from the screens alone.
Check what each person is allowed to do
Describe the roles in your product and what each role may view or change. Hiding an admin button in the interface is only part of the experience; protected actions and data also need enforcement on the server.
In a customer portal, for example, test that one customer cannot retrieve another customer’s records and that removing a staff member’s access has the intended effect. The OWASP Application Security Verification Standard is a reference for structuring application security verification. The checks selected for your product should reflect its data and risks.
Walk through failures and repeated actions
A customer may lose connection, refresh a page, submit twice or return after an integration times out. We need an agreed result for those situations, especially when money, inventory or important records are involved.
What should happen if a payment is pending or fails?
Can someone safely retry a request without creating a duplicate?
What will the user see if an upload or notification fails?
How does staff find and resolve an incomplete operation?
For the booking example, repeated clicks should not produce multiple reservations for one intended purchase. The appropriate implementation depends on the payment provider and the booking rules; that behaviour belongs in the scope and testing.
Use representative data and realistic workflows
Test long names, empty lists, larger histories, missing fields and the devices people will use. A dashboard with five sample rows does not show how someone finds a record among thousands. Use appropriate test data rather than copying private customer information into an unprotected preview.
If existing records must move into the product, plan the mapping, trial import and checks. Decide how to handle duplicate or incomplete records and what happens to changes made during the move.
Make the release and recovery plan explicit
Know who owns the hosting and service accounts, which configuration is needed, and how the release reaches the correct environment. Before a change goes live, agree on the checks and the way to recover if it causes problems.
Recovery can involve more than restoring an older version of the code. A change to stored data needs its own approach. The team should know which backups exist, how to restore them and which checks confirm the product works afterwards.
Launch to learn, with someone responsible for the service
A controlled release to an appropriate group can help reveal problems before wider access. Decide how feedback and errors will be collected, who responds and what would cause you to pause or reverse the rollout. GOV.UK’s guidance on the beta phase describes using a limited release to learn and improve before opening a service more widely.
The core journey has been checked by: …
Permissions and important failure cases have been checked by: …
The remaining limitations are: …
The release and recovery steps are recorded at: …
The person handling feedback and incidents is: …
We will expand access when: …
These are planning prompts, not a security certification. The amount of verification should match the product and the consequences of a failure. If you have a prototype, tell me what already works and what you want to launch. I can review the next steps with you.