Your AI prototype works. What does it need before launch?
Check the user journey, permissions, data writes, integrations, deployment, and support before putting an AI-built app in front of real users.
By Nicholas Howell · Full Stack Technologies ·
Start with the release you actually need
A prototype can help you learn whether an idea makes sense. Production adds a different question: can people rely on the app to complete the intended task with their real accounts and data? Start by defining that task and the smallest audience you intend to support.
Write down what works today, what is mocked, and what still requires you to intervene. A small private pilot may need fewer features than a public launch, but it still needs appropriate access controls, honest error handling, and someone responsible when things go wrong.
Test the boundary between two users
Use two test accounts with separate sample records. Confirm each can complete the intended task, then try requesting the other account's record directly. A hidden interface button is not protection; the server or data layer must enforce access to the record and action.
For an illustrative client portal, client A should not retrieve client B's document by changing an ID in a URL or API request. Test signed-out access and privileged actions too. Keep the sample fictional and record the result so the check can be repeated after changes.
Follow the data when a request fails
Trace one important write from the form through storage and any external service. Try invalid input, a repeated submission, and an unavailable dependency. Check what was saved and what the user sees. A success message should reflect the operation that actually succeeded.
For example, an illustrative booking app must not silently create two bookings when a user retries after a timeout. If payment and booking are separate operations, define how you detect and resolve a partial failure. The required design depends on the provider and workflow; asking an agent to add a retry is not enough.
Make the app reproducible outside the demo
Confirm that someone can set up the exact revision from documented steps. Identify required accounts, configuration, licenses, external APIs, and recurring charges. Keep secrets out of the browser bundle and repository, and use separate test credentials where available.
Try the important flow on a phone and with a keyboard. Labels, focus, loading states, and useful errors are part of a working release. Check expected usage and any slow or costly operation with representative data; do not infer capacity from a fast demo with three records.
Know how you will release and recover
Record the candidate revision, checks run, unresolved findings, and required configuration or data changes. Decide who can deploy and what they will verify immediately afterward. Set up an appropriate way to detect failed requests and important user-flow failures without collecting unnecessary private data.
If the app stores valuable data, establish backups and test the relevant recovery steps. Reverting application code may not reverse a database change. Decide who responds to incidents, what support is available, and which operating costs continue after handoff.
Turn the findings into a launch decision
Separate launch blockers from later improvements and unanswered questions. A useful note says what was tested, on which revision and environment, what failed, and who owns the next action. Avoid describing a limited review as a guarantee about every feature or future load level.
Keep the parts of the prototype that meet the requirements. Repair a contained failure where possible; investigate a replacement when the existing design cannot support the necessary behavior. You need an evidenced next step, not an automatic rewrite.
Discuss your prototype →