BUILD OS · PRODUCTION READINESS

An AI-built app works, but is it ready for production?

Short answer

A working demo proves that one path ran once; it does not prove that access control, payment state, failure recovery, backups or production visibility work. Choose the checks that apply to the product and verify them in staging or a production-like environment before inviting real users.

Symptoms

  • Only the happy path has been exercised.
  • Nobody knows how an error or failed payment becomes visible.
  • The team cannot explain how data is restored or access is revoked.
  • A coding agent’s “done” message is the only acceptance evidence.

Why this happens

Production readiness depends on system behavior across users, dependencies and failure states. Source inspection can find signals, but it cannot prove deployed configuration or end-to-end behavior.

Most likely causes

  1. The acceptance criteria describe screens rather than user-visible system outcomes.
  2. Security, monitoring and recovery were deferred as “later”.
  3. Manual provider settings are assumed from source code.
  4. Changes are accepted without a regression check.

How to diagnose it

  1. List critical user journeys and the data, identity, payments and providers each depends on.
  2. For each journey, test success, denial, timeout, duplicate request and recovery where relevant.
  3. Review deployed secrets, database policies, alerting and backup restoration separately from source.
  4. Record what is verified and what remains unknown.

Fix

  • Prioritize blockers by user harm and reversibility.
  • Add focused tests for authorization, billing transitions and failure recovery.
  • Make errors observable and assign an owner for alerts.
  • Keep a short launch checklist that separates verified facts from assumptions.

Verify the fix

Do not close the issue until these checks pass in the environment that matters:

  • A second user cannot access the first user’s private data.
  • Critical external failures are visible and have a recovery path.
  • A restore or rollback procedure has been exercised where data loss would matter.
  • Each launch-critical check has a concrete result and environment recorded.

Related Ship Passport checks

Build School’s production-readiness standard marks this area as proven only with evidence from these checks (it is Build School’s own standard, not an external certification):

  • criticalThe core flow works end to end
  • criticalThe flow is tested on the production URL
  • criticalEvery environment variable is set per environment
  • importantProduction errors are captured
  • criticalAutomated backups are enabled

Common false fix

A high checklist completion percentage or a static scan with no findings is not a production certificate; the environment and real journeys still need verification.

Documented evidence

Documenté

Un écran fini ne prouve pas que l’accès, les erreurs et les opérations tiennent face à un vrai usage.

Source note: une-demo-ne-teste-pas-un-produit · Updated 2026-09-26. This is documentation provenance; it is not a claim about frequency.

Primary references

Related pattern

Verify the current behavior before asking an agent to refactor it →

Build OS stage

Production readiness · Explore Build OS →

Run ShipCheck →Learn the systemGet help fixing it