Production readiness checklist for startups and AI-built apps

Define what production must support

Start with the customer journey and the consequences of failure. A private pilot and a service that processes customer payments have different exposure. Record expected traffic, data sensitivity, support hours, external dependencies and the business actions the application must complete.

Describe the first launch scope explicitly. Limiting tenants, features or concurrency can make a launch more manageable, but those limits must be enforced and observable. Avoid calling a system ready on the assumption that users will not exercise an untested path.

Check the five operating foundations

Use the table as a starting point for review. A checkbox is useful only when it points to evidence. If the answer is unknown, record it as unknown and assign a concrete next action. That is more actionable than an optimistic pass.

Prove a release and a recovery

Build from a known source revision and deploy through the normal path. Verify login, a core business action and an unauthorized request on the destination hostname. Record the artifact and configuration that reached the environment so the team can identify the current version during an incident.

Then deliberately fail a release in an isolated environment. Confirm that checks stop it or that rollback works as designed. If a schema change is involved, test old and new application compatibility. Data recovery needs a separate drill; redeploying a previous binary does not restore deleted records.

Exercise customer impact and access boundaries

Monitor the actions customers care about, including accepted background jobs reaching completion. Confirm alerts reach a person who can act. Write a recovery objective that reflects business needs, then test how long restoration actually takes and what data window is recoverable.

For security, use two accounts to test tenant isolation. Verify server-side authorization on protected actions, review public storage and network exposure, and inspect logs for secrets. A successful sign-in test does not prove that one signed-in customer cannot access another customer's data.

Turn findings into a short action plan

Prioritize a small number of gaps by expected impact, exposure and recovery difficulty. A missing restore path for essential data usually deserves attention before a dashboard polish task. Assign an owner, acceptance evidence and a due date for each action. Explicitly record any risk the team accepts for the launch scope.

Cost and ownership deserve the same treatment as deployment. Set usage boundaries around model calls and worker concurrency, tag resources to owners and confirm escalation responsibilities. A service can be technically available while consuming an unsustainable budget or waiting for an alert no one receives.

For teams giving coding agents cloud access, Latifold's Cloud Readiness for Coding Agents check asks ten questions about infrastructure context, permissions, policies, resource ownership and verification. It provides a self-assessed score and an action plan after a work-email submission. Use it alongside the production checks above; verify the controls in your own environment before expanding agent access.