How to Use the New Project Pre-Start Checklist

I built this checklist after noticing the same pattern too many times: a project stalls or goes sideways, and when I trace back why, it's almost never a coding problem. It's a problem I could have caught in ten minutes of research before I ever opened an editor. This is the checklist I now run before every client build, portfolio project, or automation — here's how to actually use it instead of letting it sit as a nice PDF.

The rule that makes it work

Use it before writing the first line of code, every single time — even when the project feels small or obvious. The checklist is explicit about this: "photocopy this mentally... for every new project going forward." Skipping it on the projects that feel simple is exactly when scope creep and missed requirements sneak in, because nobody was watching for them.

How to work through the 10 sections

1. Fill in the top fields first — always, literally. Project name, who it's for, start date, target completion date. This takes 90 seconds and forces you to commit to a real deadline instead of a vague one.
2. Section 1 (Problem Definition) is the one you cannot skip. Write the one-paragraph problem statement and the concrete success criteria for real — not "make it good," but a specific number or deliverable. Everything else in the checklist is secondary to getting this right.
3. Sections 2–4 (Domain, Technical, Competitor research) — timebox them. Give yourself 30–60 minutes total, not a full day. The goal is "know enough to not be blindsided," not exhaustive research.
4. Section 5 (Scope & Setup) — do this literally, not mentally. Actually create the folder/repo, actually install and verify the tools work, actually start the README, even if it's two lines. "I'll set it up when I start coding" is how half of this checklist quietly gets skipped.
5. Section 6–7 (Data/Content, Risk & Legal) — this is where client work specifically gets protected. Confirming licensing and data privacy before you build saves you from redoing work later when a client asks "wait, can we actually use this image/dataset?"
6. Section 8–9 (Planning, Documentation) — set your "definition of done" in writing. This single line prevents the most common freelance trap: polishing indefinitely because "done" was never actually defined.
7. Section 10 (Final Go/No-Go) is a hard gate. If you can't honestly check every box, you're not ready to start building — go back and fill the gap, don't rationalize past it.

Every project — technical or not — fails or succeeds based on how clearly the problem was defined before work started.

How I actually use it day to day

I keep one blank copy and literally re-fill it for every new project — client work, a new portfolio build, a new automation. It takes about 20–30 minutes total for a small project, and closer to an hour for client work where the legal/data sections actually matter. That 20–30 minutes has saved me far more time than it costs, almost every time.

Where this fits with your other prep

Pair this with your task tracking tool of choice (Notion, Trello, whatever you already use) — the checklist tells you to decide on one, not necessarily to use a specific one. If you're building something for the Resources library, teaching cohort, or a client, this is the step right before you touch the keyboard.