Buyer’s guide

Is your AI-built prototype ready for production? A practical review checklist

Review an AI-built app before launch: architecture, permissions, data integrity, testing, deployment and recovery. Decide what to keep, repair or rebuild.

By 3 min readSaaS founders & product owners

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.

A production-readiness review checks identity, business data, user journeys and operational recovery before launch.
Launch readiness combines product behavior with the ability to operate and recover the system.

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.

Use a launch checklist tied to real journeys
AreaEvidence to ask for
Core journeyA repeatable check from account creation to the customer’s intended outcome
Access controlRejected cross-account and unauthorized requests
Data integrityChecks for duplicates, invalid states and partial failures
OperationsA 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

James Drummond

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 →

Continue reading