Website launch checklists are usually PDFs or documents. That is fine until several people need to work through one, the tab closes, or the checklist needs to be reused without sending data to another service.
I built a small open-source version that runs entirely in the browser:
- Live tool: https://bryceelliot.github.io/website-launch-checklist/
- Source: https://github.com/bryceelliot/website-launch-checklist
It is intentionally simple: one HTML file, semantic controls, no framework and no analytics.
Start with native controls
Each item is a native checkbox wrapped by a label. This provides keyboard operation and a larger pointer target without rebuilding checkbox behaviour in JavaScript.
<label>
<input type="checkbox" id="domain-control">
<span>The business controls the domain registrar account and recovery email.</span>
</label>
The progress element is also native:
<progress id="progress" value="0" max="36">0 of 36</progress>
The JavaScript updates both the numeric value and an accessible label. A screen-reader user gets the same progress information as a sighted user.
Store state locally
There is no account and no server. Checked item IDs are saved to localStorage in the visitor’s browser.
const key = 'elliot-launch-checklist-v1';
const checked = [...boxes].filter(box => box.checked).map(box => box.id);
localStorage.setItem(key, JSON.stringify(checked));
On load, the page reads that array and restores matching controls. This is suitable for a personal checklist because the data is not sensitive and does not need to move between devices.
The reset control clears only this checklist’s storage key and returns focus to the first item. It does not erase unrelated browser storage.
Keep printing useful
A checklist is often used in a launch meeting, so the page includes a print stylesheet. Navigation controls disappear, colours simplify and the content lays out as a document instead of a captured web page.
The print button calls window.print(), but the page remains printable without JavaScript through the browser menu.
Group checks by launch risk
The code is the easy part. The wording determines whether the tool is useful.
The 36 checks cover:
- ownership and account recovery
- content and customer journey
- mobile and accessibility
- search foundations
- redesign redirects
- forms and measurement
- security and resilience
- performance and compatibility
- post-launch monitoring
Each item describes an observable condition. “Do SEO” is not a check. “The XML sitemap contains canonical, indexable URLs only” is.
Verification
I tested the public build for unique checkbox IDs, persistent checked state after reload, reset behaviour and working destination links. The repository is MIT licensed, so it can be adapted to another workflow.
For the broader reasoning behind the search and redirect checks, I wrote a separate website redesign guide:
Elliot Digital’s web-design approach is documented here:
Top comments (0)