Project delivery and launch checklist

How to use this checklist

Mark relevant items as passed or unresolved. Use not applicable for features that do not exist. Record the date, version, examples tried and open issues. After a substantial change, repeat checks for the affected work.

Start with sections 1 and 2 for every project. Add section 3 for websites, and the relevant later sections for backends or accounts. Payments, sensitive data and critical business tasks require additional checks for the actual features.

1. Goal, material and versions: every project

[ ] The user, intended result and excluded scope are clear.
[ ] Sources and dates are correct; missing or conflicting information is listed.
[ ] Originals are kept and the previous version can be recovered.
[ ] The responsible person has confirmed any publishing, sending, payment or deletion.

2. Result and use: every project

[ ] The page, tool or file opens, and the recipient knows where to start.
[ ] Numbers have been recalculated, conclusions trace to sources and fictional data is labelled.
[ ] Format, text, images and links are checked at the actual reading size.
[ ] Another normal input has been tried; missing material is flagged rather than invented.
[ ] Repeated workflows describe inputs, steps, output and human confirmation points.

3. Websites and browser tools

[ ] The final address is accessible, with working HTTPS for public sites.
[ ] Phone reading, typing and tapping work without overlap or horizontal overflow.
[ ] The main path works end to end, including refresh, back and important links.
[ ] Blank, malformed or out-of-range inputs have clear feedback; calculations match known examples.
[ ] Pages expose no keys, test accounts or information that should not be public.

4. Backends, APIs or saved data

[ ] Production configuration and dependencies are set, with build and startup steps recorded.
[ ] Production APIs and data reads/writes have been tried; test data stays separate.
[ ] Timeouts, service failures and repeat submissions have handling users can understand.
[ ] Runtime errors are visible to the operator, without exposing keys or personal data in logs.
[ ] Important data is backed up, recovery is understood and failed releases can return to a working version.

5. Accounts or different data access

[ ] Restricted data cannot be retrieved without login.
[ ] Two different accounts have been tested; each can read and change only permitted data.
[ ] The server checks permission on reads and changes; hiding a button is not the only restriction.
[ ] Logging out, opening a direct link or changing a record ID does not expose another account's data.

6. After delivery

[ ] An intended user has tried it; confusing or broken steps are recorded.
[ ] The final address or file, instructions and known issues are kept, with a person responsible for updates.
[ ] Future changes include checking that the original main task still works.

For documents and content, use the comparison exercise to practise checking. For websites, return to the first website path to plan publishing and real use.

Questions

Must every project pass every item?

Select what matches the actual features. A static page usually has no database or account access. Mark absent features as not applicable and ask about anything uncertain.

Does completing the checklist guarantee there are no problems?

No. It covers common checks, not every case. Payments, sensitive information, complex access rules and critical business functions need checks tailored to the actual project.

Download the Markdown file

Select relevant items and record results and open questions.

Download Markdown

Delivery and launch checklist for your first project