How we review a site before release

A successful build is one piece of release evidence. We also need to inspect the delivered pages, their data and the tasks people will perform.

Engineering · 2 min read · Theo Grant

How we review a site before release

How we review a site before release editorial visual

A successful build is one piece of release evidence. We also need to inspect the delivered pages, their data and the tasks people will perform.

Use the production output

Review the compiled application with realistic content and environment settings. Check route responses, image loading, client hydration and the network requests the page actually makes.

Walk the important journeys

Navigate with a keyboard, submit forms with valid and invalid input, and inspect the result. Repeat the key tasks at small and large viewport sizes. Record limitations alongside the checks that passed.

Prepare the recovery path

Write down how to identify the running release and how to restore the previous one. Confirm who owns content changes and operational alerts. A release is easier to support when these details are agreed in advance.

Use a small release record that names the build, the checked routes and the known limitations. A future maintainer should be able to connect a reported problem to the exact version that was reviewed.

← Return to the journal

Keep exploring

More from the studio.