Your AI-built app is ready for customers when its main job works on the published version, people can only access what belongs to them, and you can support and recover it when something goes wrong. A convincing demo doesn't establish those things. Neither does the AI tool saying the project is finished.
You don't need every feature on your wish list before launch. You do need evidence for the features you are asking people to rely on. This checklist helps you make that decision for a small business web app, whether you built it with Lovable, Bolt, Replit or an AI coding assistant.
Decide what you are actually launching
Write one sentence describing the first useful version. For example: “A customer can sign in, submit a job request with a photograph, and see our reply.” This is a fictional example, not a Right Cyber customer project.
That sentence creates a manageable launch boundary. Online payments, live chat and automated quotations can wait if the first version doesn't promise them. Saving the request, keeping the photograph private and delivering the reply cannot.
Also record who will use it, what information they will enter and what happens if it is unavailable. A private trial with three staff members has different operational needs from a public service taking customer payments. Calling a release a beta doesn't make lost records or exposed files acceptable.
Seven questions to settle before launch
1. Does the whole customer journey work on the published app?
Start from the address customers will receive, using a fresh browser session and a test account. Complete the main task from beginning to end, including any confirmation email, uploaded file and staff action. Sign out, return and check that the result is still there.
Record the app version, date, browser and outcome. A preview can have different settings, credentials and callback addresses from the live app. A successful preview is useful evidence about the preview.
For the fictional job-request app, “the submit button works” is too vague. Useful evidence is: “Request TEST-014 is saved once, its photograph opens for the authorised member of staff, and the reply arrives at the test customer's email address.”
2. Can the wrong person see or change anything?
Ask a developer to check access rules for records, downloads and administrative actions. Signing in establishes identity. It doesn't, by itself, restrict a person to their own information. OWASP's authorisation guidance explains that permissions need checking on requests, including access to individual resources, rather than relying on hidden buttons in the browser.
Use separate fictional customer accounts in an approved test environment. The evidence you want is that customer A cannot open or change customer B's request, even through a direct link. This needs review below the visible screens as well as checks through the interface.
3. Do failed or repeated actions leave a sensible result?
Use an isolated test environment with fictional records to work through an interrupted upload, an expired sign-in and a repeated submission. Confirm that it cannot send messages or change records for real customers. The app should tell the person what happened and what to do next. It should not show a success message before the important work succeeds.
Where payments are involved, use the provider's test mode and include declined payments and payment notifications arriving more than once. Stripe documents duplicate webhook deliveries, so an integration must account for them. The desired business result might be one order and one entitlement, even if a notification is repeated. Ask for evidence for your payment flow, not just a screenshot of checkout.
4. Can customers actually use the screens?
Check the main journey on a narrow phone screen, with the keyboard and with enlarged text. Look for labels that explain each field, visible keyboard focus and errors that help the person recover without losing their work.
W3C's accessibility checks are a useful starting point. They cover only part of accessibility, so passing a quick check is not a claim that the app meets an entire accessibility standard. Include an appropriate accessibility review in the work needed for your audience.
5. Can you restore records and undo a bad release?
Identify the backups for the database and uploaded files separately from the saved code. Ask whoever maintains the app to demonstrate recovery in an isolated environment and explain what information would be missing after a restore.
Also ask how a failed software release would be reversed. Putting yesterday's code back does not automatically undo a database change or recover today's deleted files. The recovery plan needs to fit the app's actual storage and release process.
6. Will someone notice when the important job stops working?
A homepage that loads doesn't prove that requests are saving or emails are arriving. Decide which failures need an alert and who receives it. Give that person a way to inspect an affected request without placing passwords or unnecessary customer information in logs.
Check who controls the domain, hosting, database, email service and payment account. Record the expected monthly costs and available usage alerts. The business should know who can restore access if the person who built the app is unavailable.
7. Has the code and configuration had an appropriate review?
Give the reviewer the intended behaviour, access to an isolated test setup and the exact version proposed for release. Include the external services the app uses and any changes to stored data. Ask for findings organised by consequence and a retest of the corrections.
GitHub's guidance on AI agents calls for reviewing and testing generated code. An automated review can help find issues, but its approval doesn't demonstrate that all business rules, permissions or recovery arrangements work.
Turn the findings into a launch decision
Use a short release record rather than a percentage score:
- Release candidate: the exact version and intended audience.
- Evidence: the completed journey, technical review and recovery checks.
- Blockers: failures that could expose information, lose important records, charge incorrectly or prevent the promised task.
- Accepted limitations: clearly described omissions that don't undermine that task, with an owner and next review date.
- Support: who watches the release, how customers report a problem and when the release would be paused.
In the fictional example, an unfinished colour theme can wait. A request that disappears after sign-out blocks the release. A photo that another customer can open blocks it too. Those decisions follow the consequences, not the number of ticks in a checklist.
Once the blockers are resolved, a controlled first release lets you observe the app with a manageable audience and support it closely. If you cannot yet establish what the app does with customer data or how to recover it, the next useful step is a software review and completion plan.