A demo shows that something can work. A release needs a clear account of what works, what is exposed, what it costs to keep running and what you will do if it fails. Use this checklist for a website, a marketing workflow or a business-intelligence report, marking irrelevant items as not applicable with a reason. Increase the depth of review as the sensitivity of the data and the consequences of failure increase.
What you will leave with
A concrete release decision supported by checks, an operating note and a recovery plan, with unresolved blockers clearly identified.
Step 1
Verify the main job on the actual release
Choose the two or three actions that make the project useful. For a page, follow its main action. For a tracker, create and retrieve an item. For a marketing dashboard, reconcile totals and rate denominators against the source, with matching dates, time zones and definitions. Run the applicable build and tests, then try those actions at the exact deployment URL. Record the revision or report version tested, and review marketing claims against their cited evidence. A polished screenshot, passing build or successful homepage response does not demonstrate the full user journey.
The intended audience can complete the main actions on the version you plan to share.
Step 2
Check the reading and interaction experience
Use a narrow screen, zoom the page and navigate with a keyboard. Confirm that text remains readable, controls have clear labels and error messages tell people what to do. Check loading, empty and failure states where real work occurs. Respect reduced-motion preferences and keep decorative effects from blocking input or shifting content. A first release can be small, but the path it offers should be complete and understandable.
The main flow remains usable with a phone-sized viewport and keyboard, including a realistic failure.
Step 3
Verify access and secret handling
List which information is public, private and administrative. Check the browser bundle and repository for credentials that should remain on the server. For an app with accounts, use two normal test users and verify that neither can access the other's private resources. Exercise the API or data path as well as the visible page. If there is no login or private data, record that simpler design rather than adding authentication for its own sake.
The access rules match the intended audience and no privileged credential is exposed to clients.
Step 4
Know what survives and what can be restored
Identify where code, database rows and uploaded files live. Do not assume files written inside a running service survive replacement; use the platform's appropriate persistent storage. Check actual backup coverage, retention and restore procedure. Supabase database backups do not include Storage API objects, while Railway volume backups are a separate recovery mechanism. Practice recovery with sample data in an isolated environment instead of discovering missing coverage after a loss.
The recovery note names each data store, its backup and a tested or explicitly untested restore path.
Step 5
Set a cost boundary you understand
Inspect the current plan, running resources, external APIs and usage controls. Decide who receives alerts and who can stop a runaway task. A budget alert may only notify you. Vercel's optional production pause has limits and does not end every charge; Railway distinguishes compute and agent limits, with different consequences. Check those current behaviors before enabling them. Do not promise a universal spending cap or assume deleting the frontend removes database and storage costs.
You know what creates ongoing usage, what the configured control does and what may remain billable.
Step 6
Prepare an operating and recovery note
Write down the owner, repository, production URL, hosting project, important configuration names and where to find errors. Include the previous working deployment and how to restore it. Keep secret values in the appropriate secret store, not the note. Distinguish rolling back application code from reversing a schema change or restoring data. For a recurring job, test a manual run, a failed run and a safe retry before relying on the schedule.
Try this instruction
Review this release against the project's stated user journey or business decision. Report evidence for function, metric reconciliation, source and claim review, narrow-screen and keyboard use, access rules, secret placement, data recovery, costs and rollback. Mark irrelevant items with a reason. Separate passed checks, failed checks and checks you could not perform. Do not declare the project production-ready merely because its build passed.
A responsible person can find the system, diagnose a failure and begin recovery without guessing.
Step 7
Make a specific release decision
Summarize passed checks, open defects and practical limitations. Decide which failures block release, such as exposing private data or breaking the main action, and which can be documented for a limited pilot. Share first with the intended small audience and watch for actual failures. Record feedback against the version they used. A useful launch creates a maintained project with clear ownership; the final deployment message is the start of that responsibility.
The release note states what is ready, who it is for, its known limits and who responds to problems.
When you get stuck
The checklist is full of unexplained green boxes
Attach a URL, observation or test result to the important checks. Keep unperformed checks visibly unverified.
Rollback is expected to repair lost data
Write separate recovery steps for application code, schema and stored information.
A scheduled job produces duplicates
Test a retry using the same input and define how the job recognizes work already completed before enabling unattended runs.
Terms explained
- Release blocker
- A failure serious enough that the intended audience should not receive this version.
- Persistent storage
- Data storage designed to outlive a particular running application instance.
- Idempotent retry
- Repeating an operation without duplicating its intended effect.
Sources and further reading
The workflow and templates are teaching guidance. The sources below support the underlying tools and concepts; product setup and availability can change.
Take it into your next task
Your completion checklist
0 / 7 checked
Checks are saved on this browser. Mark them only after you inspect the evidence. These are your checks, not an automated certification.