The short answer
An AI-built prototype is ready for production when its important behavior has been verified and someone can operate and recover it. A convincing demo is evidence of progress; it does not establish permissions, data integrity or reliability under real use.

Start with a review, before choosing a rewrite
A prototype can contain useful product learning and sound implementation alongside serious gaps. Separate those questions. Does the product solve a worthwhile problem? Is its current implementation an appropriate foundation for real customers? Neither answer follows automatically from the other.
Begin with a bounded architecture and code review. Record what exists, what is missing and what cannot yet be verified. Rank findings by business impact. An isolated authorization bug, an untested billing flow and an inconvenient folder structure should not receive the same priority.
Check access from the server’s point of view
Hiding a button is not an access-control check. Verify that the server rejects unauthorized requests even when someone calls an endpoint directly. For a product serving multiple businesses, test that one organization cannot retrieve or alter another organization’s records.
Check invitation, password reset and account deletion behavior. Look for credentials in browser code and repository history. Give development, testing and production separate access arrangements. The aim is to identify concrete failure paths, rather than assume that the presence of a login screen establishes security.
- Can an ordinary user perform an administrator action?
- Can a user change an identifier to access somebody else’s data?
- Are secrets held on the server and restricted to the permissions required?
Test what happens to business data when things fail
Choose the records whose loss or duplication would matter most: orders, bookings, payments or customer documents. Trace how they are created and changed. If an external service times out, can a retry create the same booking twice? If a user refreshes during checkout, is the final state clear?
Use examples agreed with the business owner. A fictional test shop might require one order and one receipt even when a payment callback is delivered twice. That is a checkable rule. ‘The checkout works’ is too vague to guide either a developer or an agent.
Use a launch checklist tied to real journeys
Tests generated from the same code can miss the same assumption. Start with behavior the business needs, then use automated checks and browser journeys to verify it. Include denied access, empty inputs, partial failures and recovery, not just the expected path.
OWASP’s Application Security Verification Standard provides a structured set of security requirements that can inform a review. Using a checklist is a way to define work; it does not turn an application into a certified or risk-free system.
| Area | Evidence to ask for |
|---|---|
| Core journey | A repeatable check from account creation to the customer’s intended outcome |
| Access control | Rejected cross-account and unauthorized requests |
| Data integrity | Checks for duplicates, invalid states and partial failures |
| Operations | A tested deployment, backup restoration and rollback procedure |
Know who can deploy, diagnose and recover it
A production system needs a reproducible deployment, useful logs, alerts for important failures and backups that can actually be restored. Decide who responds when it breaks. Check that the business controls its hosting account and has the documentation needed for another engineer to take over.
The output of a readiness review should be a release decision with explicit conditions: launch after these fixes, restrict the first release to this scope, or rebuild this particular component. Preserve working parts where that makes sense. The objective is a supportable product, not a rewrite for its own sake.
Sources & further reading

About James Drummond
Founder of Yellow Melon and senior full-stack developer. James built and sold Smoothbook and has worked on systems for Universal Music Group, AllSaints and financial-services businesses.
Professional background →

