A successful build proves that the project can be compiled or assembled. It does not prove that visitors can submit an enquiry, editors can publish a page or an integration can complete its work in the deployed environment.
Choose release checks around the journeys that matter to the business. Keep the set small enough to run consistently and specific enough that a failure leads to a useful decision.
Identify the critical journeys
List the actions whose failure would materially affect the site. For a service business, that may include landing on a service page, opening the contact form and delivering a test enquiry. For a property operator, add search, date selection and the booking handoff.
Include an editorial task if staff will maintain the site. A release that preserves the public homepage while breaking the editor's normal update process is still incomplete.
For a hypothetical agency launch, five well-chosen journeys can provide more confidence than a long checklist of disconnected visual details. The exact number matters less than whether the journeys reflect how the site creates value.
Make the expected result observable
“Test the form” is ambiguous. “Submit a clearly labelled test enquiry, confirm the stored record and verify delivery to the agreed test recipient” tells the reviewer what evidence to collect.
Use safe test accounts and destinations. Avoid creating real bookings, customer notifications or other external side effects simply to establish that a button works. Where the final live step cannot be exercised safely, document the test boundary and the remaining operational check.
For integrations, include one failure state. A provider timeout or unavailable search should produce the intended recovery message rather than a blank result. Happy-path checks alone miss behaviour that becomes important during the first incident.
Check the deployed environment
Configuration can differ between local, preview and production environments. Confirm that the release has the required variables, asset paths and execution arrangements. Check representative pages directly rather than relying only on navigation from the homepage.
Review canonical URLs, indexing controls and social previews for pages intended to be public. A temporary noindex setting or a preview hostname in metadata can survive a visually successful launch.
Where URLs have changed, test the important old routes and their final destinations. Keep internal links pointed at the current pages so normal navigation does not depend on historical redirect chains.
Decide what stops the release
Agree which failures block launch and which can be scheduled as follow-up work. A cosmetic spacing issue and a lost enquiry should not have the same priority. The decision belongs in the release plan before the team is under time pressure.
Name the person who can authorise a rollback and define what rollback actually reverses. Restoring code does not necessarily undo a database migration or an action already sent to another system.
Record the checks, the build reviewed and any accepted limitations. That gives support a useful starting point if a problem appears later. Our development process connects implementation, review and release so the final approval refers to demonstrated behaviour rather than a reassuring build log.