The pre-launch checklist

A pre-launch checklist is a list of checks in six blocks to pass before a site goes live. A blocker is never left unfixed, and every other finding gets a date.

A launch as a list, not as a mood

So far in this part you have checked the site in pieces: speed, accessibility, security, the form, the law. One last step remains: to gather everything and decide whether it can go live. That decision is made not by feeling (“it seems to work”) but by a list that you go through item by item and write down. A list doesn’t guarantee a perfect site. It guarantees that you won’t launch a site on which you didn’t check the most important things.

Three principles make a list work.

1. A blocker and a remark are different things. A blocker is an item without which you don’t launch: a broken form, HTTPS without HSTS, no backup, an empty consent under a form that collects data. A remark is a shortfall you can launch with, if you write it down and give it an owner and a date. You choose the blockers in advance, while there is no temptation to say “oh, it’ll be fine.”
2. A block’s color comes from facts. A block is green when everything is checked and in order; yellow when there are remarks; red when there is a blocker. The color is not bent to match what you wish.
3. The verdict follows from the report. A red block means “not ready,” with a date and an owner in the report. “Not ready” with a plan beats “ready” with no check.

The six blocks

The blocks repeat what you have been through. In brackets, where an item comes from.

1. Speed and reliability. The measures in the green zone on a mobile network, images with sizes, a written budget (lesson 1); a backup with a tested restoration and uptime monitoring (the part on infrastructure), and a way to roll back a deploy.
2. Accessibility. Automated checks with no serious errors, a keyboard walkthrough, contrast and target sizes, the main action with a screen reader (lessons 2 and 3), and an honest accessibility statement (lesson 13).
3. Security. HTTPS and HSTS, headers and CSP, a second factor on email, domain, hosting and repository, no keys in the repository, and the form checked on the server (lessons 5 and 6).
4. Law. A record of processing, with where the data is stored and any transfer outside the UK or EEA; a separate consent where you rely on consent, and a privacy notice; a cookie table and a banner (with Global Privacy Control honored); a register of materials with licenses; texts checked against advertising law and your profession’s rules; and a terms page if you sell (lessons 7 to 12). All with the caveat that the final verdict is a lawyer’s.
5. Search and analytics. Titles and descriptions, a sitemap and canonical addresses, link previews, a counter with goals and tags, and the site in webmaster tools (the parts on SEO and metrics).
6. The main action and content. The main action works on a phone from start to finish, and also where the script didn’t load; end-to-end tests are green; contacts are the same everywhere; there are no broken links, and the texts are proofread.

The thirty checks, five to a block, are gathered in the diagram. Mark them and watch how the colors of the blocks and the verdict change.

What to check by hand

Tools and tests help, but some things only a person sees.

• A phone. Take a real phone, go onto a mobile network and go through the brief’s main action from the first page to the result. Does everything read without zooming? Does your finger land on the buttons? Does a banner cover the form?
• Without the script, and on a bad network. What happens if the script didn’t load? Does the form submit with an ordinary request, do links lead to addresses? (Progressive enhancement from the JavaScript part.)
• Contacts. The phone, email and address are the same in the header, the footer, the contacts page, the privacy notice, the map listing and the profiles. A mismatch undermines trust and hurts local search.
• The live site, not only the test one. After the deploy, open the main pages again and go through the main action. The certificate, the redirects and the headers at the live address can differ from the test one.
• A backup and a rollback. You know how to return the previous version, and you have tried it.
• People. Ask one person who didn’t build the site to do the main action, with no prompting. Three minutes of watching finds what the checks don’t.
• A last look at the law. Read your privacy notice against what the site really does today; check the cookie table against the developer tools; check that every photo and font is in the register. Ask a lawyer, or the authority itself (the ICO, your national data protection authority, the FTC), about anything you are unsure of.

Launch day and after

Launch day goes calmly if it has an order.

1. Freeze changes and go through the checklist.
2. Make a fresh backup and make sure a rollback is possible.
3. Deploy.
4. Check the live site.
5. Turn on monitoring and watch it.

Work doesn’t end at launch. Watch accessibility and errors, read the speed and counter reports, add the site to webmaster tools, review the privacy notice and the cookie table whenever a new service is added, and put the checklist in your calendar (once a quarter at least).

Practice

You are in the era of “next”: a site is built from a brief and deployed at once, so checking before launch matters more than ever. Write a readiness report for your project: the color of each of the six blocks with a conclusion, a list of fixes with an owner and a date, the phone check, what happens without the script, the backup and rollback, contacts in three places and a verdict.

The check reads structure: that the blocks have colors and conclusions, the fixes have an owner and a date, the main action is named and the verdict is there. Whether the report is true is up to you: go through the checklist on a real site, not on this teaching one.

If you make an honest report for a real project and it has red items, that is a good result: a launch without a list looks green only because nothing was checked.

What used to be different

In the FTP era a site was “launched” by uploading files and phoning the client: “Take a look.” There were no checks, no backups, and a rollback meant an old folder on the desktop. Then came automatic checks, deploys on a commit and monitoring, and a launch became an event that can be repeated without fear. But the decision “ready” is still taken by a person, and an honest list helps make it without self-deception.