Quality that holds up in real use.

We treat release checks as part of the product plan. Start with the question the page must answer, then follow the action it invites: book, call, read, calculate or enquire. The test is incomplete if it ends at the button. A form should deliver a usable enquiry; a booking should confirm the correct time; a price should match the charged amount.

Check the same path on a phone, with a keyboard and with slower connections where practical. Text hierarchy, contrast, labels and focus states must make the next step understandable without relying on decoration. We also review links and page metadata so visitors and crawlers can reach the intended page.

A project can also fail quietly after a successful form submission: an email may reach the wrong mailbox, a booking may display the wrong local time, or a customer may receive no confirmation. We verify the destination with a real test and assign someone to handle each exception. Where payments are involved, the amount, currency, receipt and refund route must agree with the offer on the page.

Publishing is the start of the evidence. Review search coverage, qualified enquiries, support requests and the pages that send the wrong visitors. Document who updates advice when products, policies or platforms change. The tests and cadence depend on the actual project scope and the team's capacity.

For a practical pre-launch list, use the website launch guide ↗. To define a build and its acceptance tests, prepare a project brief ↗.

At handover, your team should be able to change a service description, correct a price, publish a schedule and locate the relevant account without a developer. We document the checks and the owner of each recurring task in the agreed scope. A later change to the offer, integration or contact destination should trigger another end-to-end test of the affected journey.