You have built an app with AI, tested the main screens and shown it to potential customers. They want to use it. Now you need to know whether it will hold up when they bring their own data and start paying.
Before you launch an AI-built app, test the situations your demo did not cover. A customer might open an old shared link, cancel a subscription or upload a file the application cannot read. You need to know how the software responds and who will fix it if something goes wrong.
You may be able to keep much of the prototype. A technical review should establish what works and which problems need attention before launch.
Define what your first customers must be able to do
Write down what a customer needs to accomplish in their first session. In a proposal tool, they might create an account, enter project details and generate a draft. They still need to edit that draft and share it with a client. Test the entire sequence.
Repeat the test with interruptions. Close the browser before the draft is saved or disconnect while uploading a file. Check whether the customer’s work survives and whether they can continue without contacting support.
Keep the launch small enough to verify. One reliable workflow gives you a clearer basis for learning than several unfinished features. Set aside optional dashboards, additional integrations and visual refinements unless they are necessary for that first journey.
Check these areas before accepting real customers
Customer accounts and access to data
A working login screen proves very little about who can access each record. Create separate test accounts for different customers and roles. Check whether a person can open someone else’s document by changing its identifier, use an old shared link after access is revoked or call an administrative action directly.
Permissions need to be enforced where data is accessed, including APIs and file storage. Hiding a button in the interface is insufficient. OWASP recommends checking permissions on every request and denying access by default when no permission is granted. See its authorization guidance.
Payments and subscriptions
If the product charges customers, test the entire subscription lifecycle. Include failed payments, cancellations, plan changes, refunds and the delay between payment confirmation and account activation.
Payment notifications can arrive more than once or in an unexpected order. Stripe documents these behaviors in its webhook guidance. Your application should verify notifications and avoid granting duplicate credits or processing the same event twice.
Ask the team to demonstrate a successful purchase, a failed payment and a cancellation. After each test, check the account’s billing record and access to paid features.
Data recovery and deployment
Ask the developer to restore a backup into a separate environment. Open the restored application and check that customer records and uploaded files are available. Record how long recovery takes and how much recent work would be lost.
Also verify that the application can be built and deployed from the repository using documented configuration. Keep production credentials out of source files. Record which services the product depends on and ensure the business has appropriate administrative access to them.
A rollback plan should account for database changes. Reverting application code may not reverse a migration that has already changed customer records.
Reliability under realistic usage
Test the first release with representative data sizes and simultaneous activity. A dashboard with ten sample records may behave very differently when a customer imports a year of transactions.
Identify expensive or slow actions, apply sensible usage limits and make failures visible to the team. Customers should receive a useful explanation when an operation cannot finish, with a safe way to retry where appropriate.
If the product itself calls an AI model, test that feature separately from the code used to build it. Include incomplete inputs, irrelevant documents, unsupported requests and unavailable providers. Measure the cost of completing a customer task, including retries and any review needed.
Support and ongoing ownership
Someone needs to receive error alerts, respond to customers and decide whether a reported issue blocks further releases. Identify that person before launch.
Keep a short operational guide covering deployment, account administration, external services and common failures. If only the original builder knows how the application works, even a modest change can become a handover problem.
Decide what to keep and what to rebuild
The fact that an application was built with AI does not determine its quality. Review the actual code, behavior, dependencies and deployment setup.
A focused repair may be enough when the core workflow works and the main gaps involve permissions, error handling or tests. A larger refactor may be necessary when the same business rule is implemented differently across several screens or when changes repeatedly break unrelated features.
Consider replacing a component when its current design cannot support an essential requirement at a reasonable maintenance cost. A full rewrite needs a stronger explanation: which requirements cannot be met, what can be reused and how the alternative reduces delivery risk.
Our article on the business risks of replacing developers with AI explains the broader ownership issue. For a launch decision, ask for a practical list of verified problems and the work required to resolve them.
What a useful launch readiness review should deliver
The review should help you make a release decision. Ask for:
- A working demonstration of the main customer journey and its failure cases.
- Evidence for each significant issue, including how it was reproduced.
- A distinction between launch blockers and improvements that can wait.
- A proposed repair scope with assumptions, dependencies and unresolved questions.
- Acceptance criteria for confirming that the repairs work.
An automated scan alone cannot establish whether the product implements your business rules correctly. Combine code inspection and automated checks with testing of the real application.
Consider a booking app that lets two customers reserve the same slot. Its screens may look finished and its unit tests may pass, but it still needs a test that submits competing bookings. This is the kind of business rule a launch review should verify.
Budget for the work the review identifies
The remaining cost depends on what the review finds. A team can estimate a few isolated defects more confidently than a project it cannot yet run. Missing repository access or undocumented integrations may require investigation before a repair estimate is useful.
Request separate estimates for assessment, essential repairs and optional improvements. Include testing, deployment and support during the initial rollout. Our guide to web application development costs provides broader planning context.
Start with a limited group whose use cases you understand. Agree on what would make you pause the rollout, such as incorrect billing or repeated failures in the main workflow. Resolve those issues before inviting more customers.
Discuss your application with Five Bricks
Have a prototype you want to launch? Contact Five Bricks with a short walkthrough and your target launch date. Tell us what already works and where you need help so we can discuss the review and development work required.
Frequently asked questions
Yes. The decision depends on the application’s behavior, security, maintainability and operational setup. Its origin alone does not establish whether it is ready to launch.
Not necessarily. Assess the current implementation first. Targeted repairs or replacement of individual components may address the problems without discarding useful work.
Start with a product walkthrough, intended user roles, known issues and a description of the stack and hosting. Arrange repository and environment access securely when needed; do not send production passwords through a contact form.