MAKIN 
Templates are decisions somebody already made.
Their value is not saving typing. It is that a good template asks the questions people forget under deadline — who signs off, what happens on failure, where the data goes. The blank page lets those questions be skipped.
The scope note is the one that earns its keep.
One page: what is included, what is explicitly excluded, what we assumed, and what changes if an assumption breaks. Most disputes we have seen trace back to an assumption nobody wrote down at the start.
Runbooks are written for a bad day.
Assume the reader is stressed, unfamiliar and working at an inconvenient hour. Numbered steps, exact commands, and the name of the person to escalate to. Prose is the wrong format for something read during an outage.
Handover is a document, not a meeting.
A meeting transfers a fraction of what is needed and none of it is retrievable later. The handover doc — credentials, dependencies, known rough edges, what we would do next — is what makes a project survive whoever built it.
The twelve, in the order a project reaches for them
We hand templates over in the order the work needs them, not as one folder on the first day. We group ours by phase: what has to be settled before any work starts, what keeps the work honest while it runs, and what lets it go live and outlive whoever built it. Each one is short, has a named owner, and sits beside the shared board, so nobody has to ask where the latest version lives.
Before work starts: scope, people, access and data
The scope note comes first, but on its own it leaves questions open that can stall the start of a project: who can approve a change, who grants access to each system, and how data actually moves between them. The three templates that follow the scope note are there to settle those questions before the first line of work is written.
- Scope note: included, excluded, assumed, and what changes if an assumption breaks.
- Contact and sign-off sheet: who decides, who is consulted, who signs off each deliverable, and a named deputy for when they are away.
- Access request list: every system, account and environment the build needs, who grants it, when it was granted and when it was revoked.
- Data and integration map: each source, where its data goes, how often it moves, and which system wins when two records disagree.
While the work runs: decisions, updates, changes and checks
These keep a moving project legible. Of this group, start with the decision log, because a decision made on a call is easy to forget and easy to reopen late in the project. A line per decision is enough: what was decided, by whom, on what date, and which option was turned down. The weekly update pairs with the working demo, so the client sees the same picture in writing that they saw on screen.
- Decision log: one line per decision, with its owner and the rejected alternative.
- Weekly update: what shipped, what is blocked, what we need from the client, what comes next.
- Change request: what is asked, why, what it displaces, and its effect on price and delivery, agreed before anyone starts on it.
- QA checklist: the checks a release must pass, ticked by someone other than the person who built it.
What the QA checklist should actually check
A QA checklist fails when a line says ‘test the app’. Every line should be something a tester can mark pass or fail without a conversation. Write it from the scope note: each included item becomes at least one check, and each exclusion reminds the tester not to chase something nobody promised. Then add the checks that get skipped when a deadline is close.
- The main user journeys, end to end, on the devices the client’s team actually uses
- Bad input: empty fields, duplicates, very long values, wrong formats
- Roles and permissions: what each type of user can see, and what they cannot change
- Data arriving where the integration map says it should, with totals that match the source
- Failure paths: what a user sees when a connected system is down
- Messages and notifications reaching the right people, once
Going live, and learning from what breaks
The go-live checklist is a runbook for a single day: backups taken, access confirmed, data frozen and moved, a rollback step written down before it is needed, and a named person watching the first real transactions. The incident review is written after anything goes wrong, without blame: what happened, how it was noticed, what fixed it, and what stops it recurring. Each review should end as a new line in the runbook or the QA checklist, so the templates improve with the project.
- Go-live checklist: the ordered launch-day steps, including how to roll back.
- Runbook: numbered recovery steps for known failures, with exact commands and the escalation contact.
- Incident review: timeline, cause, fix, and the template line it changed.
- Handover document: where credentials are kept, dependencies, known rough edges, and what we would do next.
Writing a handover document the next team can use
The handover doc only works if the next person can act on it without the author on the phone. Never paste passwords into it; record where each credential is stored, who holds admin rights and how to rotate them. List every dependency with the person responsible for renewing it, such as domains, certificates and third-party accounts, because an expired one is an outage nobody needed to have. End with an honest rough-edges section and a ranked list of what to build next.
If the project moves to a retainer such as Managed Support & Growth after launch, this document is where that work starts. If you are inheriting a codebase that arrived without one, find out what you are taking on before you commit to it; that is the job of Technical Due Diligence.