How We Scope a Project Before Writing Any Code

Most bad software projects don't fail in development — they fail in the gap between what a founder meant and what a developer heard. By the time that gap shows up, it's usually three sprints deep and expensive to fix.

Before we open an editor, we agree in writing on three things: what the product needs to do, who's actually going to use it, and what "done" looks like. Not a vague pitch-deck version of these — specific enough that a disagreement about scope becomes visible on paper instead of surfacing in a delivery-day demo.

This is also where we name the risks out loud. Every project has at least one part that's genuinely uncertain — an integration nobody's tested, a workflow nobody's mapped end to end, a deadline that assumes something goes right the first time. Writing these down doesn't make them disappear, but it means nobody's surprised later.

In practice, this phase takes three to five days and produces a problem brief, a scoped milestone plan, and a short list of risks. It's the cheapest part of the entire project to get right, because changing your mind here costs a conversation. Changing your mind three weeks into development costs a sprint — sometimes more, if the change touches something already built on top of the old assumption.

We've worked with clients who arrived having been burned by a developer who skipped this step, jumped straight into code, and spent a month building the wrong thing beautifully. Discovery is slower on day one and faster for every day after it.