Production readiness means you can operate the app for its intended users, detect failures and recover from them. The required work depends on the data, actions and consequences involved. A personal static page and an app taking payments need different release decisions.
Use the deployment checklist for a particular release. This guide covers the continuing ownership around it.
Assign an owner to each important failure
| Area | Evidence before relying on the app |
|---|---|
| Access | Signed-out, wrong-user and wrong-role requests are checked |
| Data | Backups or exports exist and the required restore has been tested |
| Release | A known good application version can be restored with a data plan |
| Monitoring | A safe known failure can be found and reaches the responsible person |
| Capacity | Representative load fits the runtime and dependencies |
| Cost | Expected usage and a failure case fit the budget; limits are understood |
| Support | Users have a useful way to report a problem |
For accounts, run the authentication checks. For Supabase, include database policy tests, not just a working login page.
Decide launch blockers from consequences
Uncontrolled paid requests, missing authorization or an untested recovery path may block launch immediately. Do not automatically postpone rate limits or logs until the first week. Conversely, an advanced dashboard is not necessary for every small app if the owner can observe and handle the relevant failures.
Write down the consequence and the check. “Users cannot read another account's notes” is a requirement. “Install a particular monitoring product” is only one possible implementation choice.
Check configuration and delivery
Public configuration is public because the application intentionally exposes it, not because a variable name makes a secret safe. In Next.js, a NEXT_PUBLIC_ prefix exposes a value to browser code; never use it for a secret.
CORS is a browser policy, not authentication. Public endpoints can be appropriate; private operations still need authorization. Configure allowed origins and credential handling for your actual architecture.
Measure mobile loading and representative API latency under recorded conditions. Cache public assets deliberately and protect personalized responses from shared-cache leakage. Investigate slow database queries before adding indexes indiscriminately.
Rehearse failure and recovery
In a safe environment, simulate a dependency timeout, malformed input and duplicate state-changing request. Verify a useful user-facing outcome and restricted diagnostic information. Then rehearse the recovery that the product requires: restoring a release, restoring data or disabling a broken optional feature.
An application rollback is not a database rollback. Preserve compatibility during migrations and decide how to handle writes made after the release. Do not discover that distinction during an incident.
Budget ongoing use
Track usage by the meters the host and attached services actually bill. A user count is not enough to estimate dynamic requests, storage transfer or AI calls. The hosting comparison and API budget guide supply examples.
Distinguish an alert from a hard stop. Verify the response to a threshold and how concurrency or delayed metering affects it. Record who can change the limit and how a disabled feature recovers.
Review after launch
Repeat the core journey on the real domain after each meaningful release. Inspect errors, response time, failed actions and support reports. Keep a dated list of accepted limitations and revisit it as usage or the product's consequences change.
Google's launch checklist is a broader reference for operational questions. Scale it to the app while retaining evidence for the failures that matter.