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: 1. 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. 2. 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. 3. 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. 4. 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. 5. 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? 👇