My exact project kickoff — take what's useful, then tell me what I'm missing

How you start a project quietly decides how it ends. So instead of asking what everyone else does, let me put my own method on the table first — take whatever's useful.

Here's my kickoff, before I let myself build anything:

Brief before build. I open a brief.md and treat it as the one file the whole project has to answer to. Nothing gets built until it's clear on three things: the outcome, who it's for, and what "done" actually looks like.
Same skeleton every time. The project drops into the same numbered folder structure I reuse on everything, so I never design the container twice — I just fill it. The shape is familiar before the work even starts.
Lock scope before touching tools. I force the scope down to one sentence, and I write the non-goals explicitly — what this is not. That single step is what keeps it from quietly sprawling later.
Decide the upkeep on day one. I set how the project stays current from the start, because the mess is never made on day one — it's made on day thirty, when the context has drifted and nobody decided who keeps it honest.
The mistake I stopped making. I used to start building before the brief was finished, telling myself I'd write it up after. The build quietly locked in decisions the brief never got to question — and by the time I noticed, they were expensive to undo.

That's my version. It works for me — but I know it has blind spots I can't see from the inside.

So flip it on me: what would you do differently? Where is this weak, and what am I leaving on the table? 👇

6 comments

My exact project kickoff — take what's useful, then tell me what I'm missing