Scope Before You Build

I've seen more projects fail from unclear scope than from bad code. A client says 'build me a dashboard,' and six weeks later neither party is happy — not because the code was wrong, but because everyone had a different image of what that dashboard should do.

The cost of undefined scope

When scope is fuzzy, everyone fills the gaps with their own assumptions. The developer imagines something technical and minimal. The client imagines something rich and polished. The budget covers one. The expectation was the other.

Scope failures usually look like: endless revision cycles, features that 'weren't in the spec' but feel obvious in hindsight, and a final product that technically works but doesn't feel right to anyone.

How I scope a project

Before any project starts, I ask for a short written brief. Not a formal document — just answers to four questions: What problem does this solve? Who uses it? What's the one thing it must do well? What's success look like at launch?

From those answers, I write back a short scope summary: what's in, what's explicitly out, and what we can revisit later. This single step eliminates maybe 80% of the friction I used to have mid-project.

The 'must-have vs. nice-to-have' split

Every feature request goes into one of two buckets before the build starts. Must-haves are things the product literally cannot ship without. Nice-to-haves are everything else. The first version only builds must-haves.

This sounds obvious. In practice, it requires real pushback. Most clients have strong opinions about nice-to-haves. The job is to help them see that a fast, clean must-have version ships faster, gets real feedback sooner, and is easier to improve than a slow, bloated v1 that tries to do everything.

Scope creep is usually a communication failure

When scope creeps mid-project, it's rarely because a client is being difficult. It's usually because the original scope didn't account for something real. The answer isn't to be rigid — it's to have a clear process for how new things get added: they go on a list, they get prioritized, they move the timeline or the budget, and that conversation happens explicitly, not silently.

Clear scope doesn't make projects inflexible. It makes changes visible and makes tradeoffs explicit. That's better for everyone.