Production readiness checklist for software teams

What production readiness means for your release

Production readiness means having evidence that a service can support its intended users, protect their data and be operated through foreseeable failures. The decision applies to a defined release and audience. A successful demonstration, a green build or a completed feature list cannot establish that evidence on its own.

A demo usually follows a route the team knows well. The test account has the right permissions. The sample data fits. The dependency responds. That is useful evidence of progress, but a launch asks different questions. What happens when a request arrives twice? Can an operator find the failed transaction? What survives an application rollback?

Episode 1 of Unspoken Rules of Tech Leadership focuses on dirty data, latency under load and security before scale. This guide turns those concerns into a practical review and adds the operational questions a team needs to settle before handing a service to users.

Google's approach to production readiness reviews uses service-specific checklists rather than a universal threshold. That is the right starting point here: agree what matters for this service, then ask for evidence against those requirements.

These counts describe the workbook. They are not industry benchmarks or a model that predicts release success. If you are hardening a generated application, the separate guide to moving an AI-built app into production covers the codebase-specific work.

A production readiness checklist built around evidence

A useful production readiness checklist connects each requirement to a test result, a responsible owner and a decision. Cover critical workflows, realistic load, security and recovery. Define which failures block the release before reviewing results, and record why a check does not apply instead of leaving it blank.

Start the review with the release scope. Identify the critical journey, the intended audience, the candidate artifact and any material difference between the test environment and production. An internal preview and a customer-facing launch can reasonably have different requirements. The difference should be explicit.

Then designate the release-critical requirements. For a billing workflow, preventing duplicate business effects may be essential. For an administrative export, access boundaries and handling of sensitive records may dominate the review. The team should make that judgment before seeing a convenient set of test results.

Our production-first approach applies a related discipline to AI delivery. This checklist stays broader: it is intended for software services whether or not they include AI.

Test the inputs your demo never needed

Use representative data and deliberately exercise malformed, missing, repeated and unauthorized inputs. The requirement is a controlled outcome: useful errors, preserved valid data and predictable handling of retries. Include the point where a user is uncertain whether an action succeeded, because that is when another request may follow.

Consider a customer importing a file. The upload appears to time out, so they press the button again. A successful review should establish what the application does with the second request and how the user discovers the final outcome. A screenshot of a completed import does not answer either question.

Use de-identified fixtures where possible, with the same relevant shapes and constraints as real data. Include unusually long values, missing identifiers and records that fail validation halfway through a batch. Decide whether processing should stop, continue with a report or leave the operation available for reconciliation.

Google's reliability testing guidance includes testing failure conditions and requests known to be bad. Its broader lesson is useful: a passing test suite still has limits. Record which conditions were exercised and what remains untested.

Permission checks belong in this work too. Try the same action using a different role and, for a multi-tenant service, a different tenant. Test the protected operation itself. A hidden interface button is not evidence that the backend rejects an unauthorized request.

Choose performance targets before running the load test

A load test needs an expected workload and a definition of acceptable behavior. Record the traffic or job volume, workflow mix, payload sizes and test duration, then compare latency, errors and resource use with agreed targets. Choose targets that fit the user journey instead of copying a universal response-time number.

A background export and an interactive checkout ask different things of the system. Google SRE's guidance on service level objectives provides a basis for selecting user-relevant indicators and understanding the distribution behind a latency summary. An average can hide the requests that have become unacceptable.

In a performance report, include the chosen latency percentile and the observed value, alongside the error rate and completed work. State the workload. A result from a small collection of lightweight requests tells you little about a launch dominated by large imports or a slow external service.

Tools can enforce the decision once the team has defined it. For example, k6 thresholds express pass or fail conditions against test metrics. The tool does not choose the right conditions for your product.

Watch what fills up during the run: connection pools, worker queues, memory and other constrained resources. Then slow or interrupt a dependency. Establish whether timeouts and retries stay bounded, what the customer sees and whether the service recovers after the interruption ends. Record the bottleneck and the limitation even if the headline result passes.

Make security requirements visible in the release decision

Security readiness requires an agreed verification scope, evidence for the relevant controls and a clear disposition for unresolved findings. Include authentication, authorization, secrets and sensitive data handling. The review should identify who can accept an exception and which issues prevent the intended release.

The OWASP Application Security Verification Standard provides requirements for verifying web application controls. Use the relevant requirements with your security team. Merely linking a standard in a launch document does not demonstrate that its requirements have been met.

Check where production secrets are stored and who can use privileged access. Identify sensitive records in application storage, logs and test fixtures. Review the unresolved application and dependency findings with the people responsible for remediation. A finding needs an explanation of impact and a decision, not a reassuring status color.

NIST's Secure Software Development Framework places security practices within software development. That supports bringing security work into delivery planning rather than leaving every question for the final launch meeting.

Identify any contractual or organizational reviews with the responsible specialists and attach their decisions. This workbook helps organize that evidence. It does not establish legal compliance or replace a security assessment.

Prove how the service will be operated and recovered

Before launch, confirm that an identified responder can detect customer impact, find the affected release and follow a rehearsed recovery path. Test alert delivery, rollback or forward recovery, and data restoration. Write down the conditions that stop a rollout and who has authority to act.

Google SRE's monitoring guidance covers latency, traffic, errors and saturation. Connect those signals to the journey you are releasing. CPU graphs alone may not show that customers can no longer finish an import.

Metrics, logs and traces provide different kinds of operational evidence. Confirm that the instrumentation you actually have can help a responder investigate the relevant failure. Trigger a test alert and verify that it reaches a person who has access to the runbook and the service.

A smaller rollout can help you evaluate a change before expanding it. Google's guidance on canary releases describes evaluating a limited deployment against a control. Your release plan should state the initial audience, observation window, success measures and stop conditions.

Recovery needs its own evidence. Reverting application code may leave a changed database behind. Record how migrations, external side effects and newly written data affect the selected recovery path. For database recovery, use your platform's documented restore procedures; PostgreSQL's backup and restore documentation illustrates why the restore method and its assumptions matter.

Rehearse recovery in an isolated environment. Measure the elapsed time and verify the recovered application data against the targets your organization has chosen. An uploaded backup file alone does not demonstrate that the service can be restored.

Make the release decision

Base the release decision on the requirements and evidence for the stated scope. Proceed when required evidence is accepted. Limit the release when exposure controls and accepted exceptions are explicit. Hold the affected scope when a critical requirement is unmet or unverified. These are suggested review rules, not a validated risk score.

Use the workbook statuses consistently. Pass means the evidence meets the agreed requirement. Gap means it does not. Pending means evidence or review is missing. N/A needs a reason and reviewer approval. Count unresolved items if that helps manage the work, but do not turn the count into a readiness percentage.

For an illustrative import release, suppose retry testing shows duplicate writes and the team has not rehearsed migration recovery. If both were designated release-critical, hold the affected release, assign owners and retest. Inviting a smaller audience alone does not resolve either problem.

Record the decision maker, scope, accepted exceptions and next review condition. Someone reading the record later should be able to understand why the release proceeded or stopped. They should not need to reconstruct the reasoning from a chat thread.

For services with model-specific risks, use the separate AI deployment gates alongside this review. Evaluation quality and model behavior need their own evidence.

Use the workbook in your next release review

The companion production readiness workbook provides fillable checks, owner and evidence fields, an exception record and a release decision sheet. Download it after submitting your details, then complete it with the people accountable for delivery and operation. Save a copy for each release so the decision remains traceable.

Bring evidence references to the review instead of copying sensitive logs or customer records into the workbook. Keep those materials in your controlled systems. Where a test remains incomplete, leave the item Pending and record who will resolve it.

If the review reveals a broader delivery problem, Resourcifi's software development work is a relevant next step. For an AI initiative stalled between prototype and deployment, the guide to closing the proof-of-concept gap covers the additional engineering decisions.

Companion workbook

Bring the evidence to your release review.

Get the fillable production readiness workbook, with 20 checks, evidence and owner fields, exception approvals and a release decision sheet.

Fillable PDF · 9 pages · Save a copy for each release

Download the workbook

Enter your details for immediate access.

Name (required)

Work email (required)

Company (required)

Job title (optional)

Website

Email me future episodes and related resources from Resourcifi. Optional.

We use these details to provide this resource and record your request. See our Privacy Policy.

Get the workbook ↗

Keep reading

Related guides worth your time

← →

Strategy, architecture & ops AI Architecture Patterns Agentic design patterns explained: reflection, tool use, planning, and multi-agent collaboration, with a framework to pic... Read guide → Strategy, architecture & ops AI Architecture Patterns for SaaS: A Technical Guide Generative AI architecture for SaaS: layered design, multi-tenant isolation, LLM gateway, RAG, and security. Built by Res... Read guide → Strategy, architecture & ops AI Cost Optimization A senior-engineer guide to AI cost optimization: where LLM spend comes from, the levers ranked by payoff, the five number... Read guide → Strategy, architecture & ops AI Evaluation and Evals LLM evaluation and AI evals, explained: the eval taxonomy, how to build an eval suite, LLM-as-a-judge bias, offline vs pr... Read guide → Strategy, architecture & ops AI Features SaaS Customers Actually Want What AI powered SaaS customers actually want: the time-savers and answers they value, the automation they distrust, and h... Read guide → Strategy, architecture & ops AI governance failures: real examples and what they teach Real AI governance failures, from biased models and exposed applicant records to a rogue coding agent, with the root caus... Read guide → Agents & RAG Agentic RAG: When to Use It and How to Build It Agentic RAG explained: how it differs from naive and advanced RAG, the key patterns like corrective RAG and self-RAG, the... Read guide → Agents & RAG AI Agent for Fintech: Risk, Compliance, Ops, Customer AI agents in finance: fraud, AML, KYC and servicing use cases, how to build with money-movement guardrails and human appr... Read guide → Agents & RAG AI Agent for Healthcare: Use Cases, Governance & Implementation AI agents in healthcare: the use cases that pay off first, how to build one HIPAA-safe on FHIR with clinician review, and... Read guide →