Your AI-built app works. Is it ready for real customers?

The screen looks finished. The sign-up button works. You can create a record, generate a useful answer and show the result to a friend. That is a meaningful milestone. It is also a narrow test: one person, one account, one route through the application.

The next stage is proving that the product behaves sensibly when the conditions change. The checklist below applies whether the code was written by a person, an AI tool or both. It is a release-planning aid, not a security certification. Higher-risk products need a review appropriate to the data and actions they handle.

1. Prove who can see and change what#

Create separate test accounts with realistic roles. Try to view, edit, export and delete another account’s records. If the product has organisations, repeat the exercise across organisation boundaries. Changing a URL or record identifier should never be enough to cross a permission boundary.

Check permissions on the server or data service, not only in the interface. Hiding an admin button does not enforce access. Confirm that privileged keys remain outside public browser code and that former team members can lose access cleanly. OWASP ASVS provides a structured basis for verifying application security controls; use it to make the scope of a technical review explicit.^[1]

2. Make transactions survive retries#

A slow network can make a user press a button twice. An external service can retry a notification. Your application should have a deliberate answer to both. Test duplicate submissions, delayed responses and interrupted checkout. Check which system is authoritative when the browser and payment provider disagree.

Stripe documents that webhook events can be duplicated and are not guaranteed to arrive in generation order.^[2] If you use Stripe, verify webhook signatures and design processing so repeated events do not repeat the business action. For other providers, check their own delivery guarantees. A happy-path payment test is not sufficient evidence of a reliable order flow.

3. Restore data, not just create a backup#

Identify what the business could lose: customer records, uploaded files, configuration and access to third-party accounts. Document where the recovery copies live and who can use them. Then restore a representative copy into an isolated environment and verify that the important relationships and files are usable.

Choose a tolerable amount of data loss and a tolerable recovery time for this release. Those are business decisions, not default settings to discover during an incident. Check how a restore interacts with external events such as payments that occurred after the backup. Assign someone to reconcile that gap.

4. If the product uses AI, bound what it can do#

Building with AI and shipping an AI feature are separate choices. If your app calls a model, define which outputs are advisory and which can trigger an action. Treat external text, uploaded documents and model output as untrusted input. A retrieved document should not be able to grant a tool new permissions.

Evaluate the feature on realistic tasks, including ambiguous requests and information it should refuse to invent. Record the model configuration and evaluation cases so a change can be compared with a baseline. Put limits on spend, tool access and repeated attempts. Give the user an understandable recovery route when the model cannot finish.

If you are deciding how much autonomy to allow, our agent versus automation guide explains the difference between a predefined process and a model choosing its next action.

5. Check the experience without your own setup#

Try the main journey on a narrow screen, with a keyboard and at increased text size. Make sure labels are understandable, focus is visible and errors explain what to fix. Do not rely on colour alone to communicate status. Include people using assistive technology in the evaluation when possible.

WCAG 2.2 supplies the formal accessibility reference.^[3] These checks catch obvious problems, but completing them is not a claim of full conformance. Also test a slow connection, an empty account, long names and realistic quantities of data. The owner’s perfectly prepared account is usually the easiest case.

6. Practise operating the product#

Keep the repository, hosting and essential service accounts under business control. Write down the minimum steps to deploy, recover and rotate credentials. A technically capable contractor is still a single point of dependency if nobody else can reach the account.

7. Use a release decision, not a feeling#

For each check, record the evidence, the owner and any remaining limitation. Block release on failures that could expose another customer’s data, create uncontrolled charges or leave the team unable to recover important information. Other limitations may be acceptable for a small, clearly briefed pilot if there is a workable fallback.

After release, review real failures and support requests alongside successful completions. Expand access when the evidence supports it. The aim is not to eliminate every possible defect before anyone benefits. It is to know what you are releasing, what could fail and who will act when it does. The wider MVP build process connects this operational work to the user problem you set out to solve.

Use a release evidence sheet#

Assign an owner to each check and record the environment, date, result and supporting evidence. Choose representative test accounts and data. Do not run destructive scenarios against customers’ live records. A check passes because the expected behaviour occurred, not because someone ticked a box.

Where a check is not applicable, record why. Where it fails, state the affected journey and decision: fix before release, reduce pilot exposure, or explicitly accept a limited issue with an owner and date. Do not label an unresolved access or payment integrity failure as a cosmetic defect.

Separate AI-written software from AI behaviour at runtime#

An application can be written with AI assistance without sending customer tasks to a model after launch. In that case, normal application behaviour still needs verification. If a model reads documents or uses tools at runtime, add tests for its permissions, uncertainty and response to untrusted content.

OWASP’s prompt-injection guidance describes how instructions inside external content can affect model behaviour. Test a permitted sample document containing instructions to ignore the task or perform an unauthorised action. The document must not gain the power to change account permissions or approve a transaction.

Also test missing evidence, conflicting records, tool timeouts and usage limits. Record what the system is allowed to do without review and where it must stop. A good-looking answer does not demonstrate that a tool action was permitted or correct. The agent evaluation guide provides a starting test set.

Put this guide to work#

Frequently asked questions#

Sources and methodology#

This guide combines editorial analysis with the linked primary sources. Decision frameworks, worksheets and worked examples are our own; examples are illustrative unless explicitly identified as supplier claims or published research. We have not conducted original interviews, comparative supplier testing or a controlled experiment for this article.

1. OWASP Application Security Verification Standard ↗

   A framework for verifying application security controls, not a certification conferred by this checklist.

   Accessed 16 October 2026
2. Stripe: Receive Stripe events in your webhook endpoint ↗

   Primary documentation on webhook verification, duplicate events and delivery ordering.

   Accessed 16 October 2026
3. W3C: How to Meet WCAG 2.2 ↗

   Reference for accessibility requirements. A short manual check is not a complete conformance assessment.

   Accessed 16 October 2026
4. OWASP: prompt injection ↗

   Primary risk guidance for instructions embedded in external content. Our examples are proposed checks, not results of a penetration test.

   Accessed 16 October 2026

Source check: 16 October 2026. Platform documentation can change. Published as part of our editorial collection.

Expanded 16 October 2026 with practical decision material, downloads and topic-specific answers. Supplier and platform claims are identified by their linked sources.