1. Write down what you’re releasing
Write a short release note before changing the live environment. Include the version, features being enabled, who will have access and who can stop the release if something goes wrong. You might be the only person doing all of this; writing it down still gives you a checklist to follow. Choose a first release small enough that you can test its main workflows and recognise a problem before a customer has to report it.
- Identify the exact version and deployment target.
- List the user workflows you will check after deployment.
- Choose the person who can pause or reverse the release.
2. Test the production build
Build the product and run the version you plan to deploy. For Next.js, this is also part of the official production checklist. Walk through sign-up and the first task a customer would perform, using suitable test accounts and data. Check routes, error pages and integrations in that build. A successful compile tells you the code built; these checks tell you whether the customer can complete the expected steps with the configuration you are about to publish.
3. Check the configuration
List the required settings and the environment each belongs to. Check callback URLs, allowed origins, external service modes and which database the product uses. Keep credential values out of the release note. Next.js distinguishes public environment variables from values kept on the server; check the equivalent documentation if you use another framework. Also try the case where a required setting is missing. An understandable startup error is easier to diagnose than a feature silently failing after launch.
- Confirm the deployment points at the intended database and external accounts.
- Keep secret values out of the release notes and shared screenshots.
- Check missing configuration produces an actionable failure.
4. Rehearse database changes
Run database migrations in a suitable test environment with representative data, following the order planned for production. Consider what happens while old and new versions of the productlication may both be running. Also consider a migration that succeeds followed by a productlication deployment that fails. Can the previous code still use the changed database? If recovery needs a restore, identify the procedure and test it before release rather than discovering the steps during an outage.
5. Check how you’ll notice a problem
Choose a few checks tied to what the product does: sign-in succeeds, a background job finishes, and a paid operation reaches the expected state. Google’s SRE launch guidance includes dependencies and failure modes in release preparation. For a small product, start by checking these signals before and after deployment. Make sure an empty error dashboard means there are no recorded errors, rather than that logging was never connected. Decide who will investigate when a check fails.
6. Test the recovery steps
Write the steps needed to restore service, including any changes to configuration or data. An older application version might not work with the new schema. Uploaded files might live outside the database, and operations in external services might need to be reconciled separately. Test what you can in the agreed environment and list what remains untested. Confirm that the person responsible has the access needed to follow the instructions without relying on someone else being available.
7. Deploy and check the main workflows
Deploy the version named in the release note, then repeat the main customer workflows and examine the logs and other checks you prepared. Compare the results with what you expected. If the product supports a limited rollout, you can start with a smaller group before expanding access. Record any problems and assign the follow-up work. Leave the release and recovery notes where whoever maintains the service can find them, including after you close your development session.
- Confirm the intended version and configuration are live.
- Verify the critical flows using approved test accounts.
- Hand off open issues and the next operational check.