Production Readiness Checklist for an AI-Generated App

Document who will use the release, which workflows are in scope, what information it stores, expected traffic, supported regions, and the impact of downtime or incorrect results. A private prototype with synthetic data does not need the same controls as a public health, finance, or payment workflow. Scope determines which controls are mandatory and which can be scheduled.

Create a simple dependency and data-flow diagram. Include browsers, APIs, databases, model providers, analytics, email, payment services, and administrative access. For each critical dependency, decide what users experience when it is slow or unavailable and whether retries could duplicate a transaction.

A senior review should trace the highest-risk flows rather than sampling cosmetic components. Follow identity from login through authorization, input from request through storage, and money or irreversible actions through all side effects. Look for client-enforced security, swallowed exceptions, unbounded queries, unsafe redirects, mutable global state, and duplicated business rules.

Run type checking, linting, builds, dependency vulnerability analysis, and secret scanning in continuous integration. Generated code sometimes includes unused packages or fictional APIs, so remove what is not required and verify package provenance. Pin supported runtime versions and make the clean build deterministic.

Authentication establishes identity; authorization must still be enforced on every server-side resource and action. Test horizontal privilege escalation by attempting to read or modify another user's identifiers, and test vertical escalation against staff or administrator functions. Default-deny access is safer than adding scattered role checks after routes are created.

Validate untrusted input at system boundaries, parameterize database operations, encode output for its context, and restrict uploads by type, size, storage location, and access policy. Inventory secrets and personal information, define deletion and retention behavior, redact logs, and confirm third-party processors receive only the data they need.

Review schema constraints, ownership columns, uniqueness rules, foreign keys, and transaction boundaries. Application validation improves user feedback, but the database should protect invariants when concurrent requests race. Test repeated submissions, delayed webhooks, out-of-order events, and partial third-party failures for critical writes.

Enable automated backups appropriate to the recovery objectives, then restore one into an isolated environment. Verify record counts, permissions, and representative workflows after restoration. A provider's backup checkbox is not evidence that the team can recover within the time the business expects.

Measure representative user journeys with realistic data volume. Inspect slow database queries, connection usage, payload size, memory, cache behavior, and third-party latency. Do not extrapolate capacity from a fast local demo or optimize only a synthetic home-page request.

Introduce controlled dependency failures and timeouts. The app should bound requests, return useful errors, avoid retry storms, and preserve consistent state. Background jobs need idempotency, retry limits, dead-letter handling, and visibility into work that never completed.

Collect structured logs, request and job errors, latency, resource saturation, and product-critical success indicators. Alerts should map to user impact and reach a named person through a tested channel. Dashboards without alert ownership do not provide an operational response.

Write compact runbooks for deployment, rollback, credential rotation, data restore, and the most likely dependency failures. Schedule the launch when responsible engineers can observe it, establish decision points for rollback, and record the deployed version and schema state. After launch, review alerts and accepted risks rather than treating readiness as a one-time gate.