How I Scope a Project Before Writing Code

The most expensive line of code is the one written before anyone agreed on what was being built. I've watched projects — mine and other people's — go sideways not because the engineering was hard, but because "build me a website" meant five genuinely different things to the five people in the room. So before I open an editor, I scope. This is what that actually involves, and why it ends up protecting the client at least as much as it protects me.

This is also the honest answer to the question I get asked most: "how much will it cost?" The truthful response is that price tracks scope and complexity, and you can't price what you haven't defined. A brochure site and a multi-tenant SaaS platform are both "a website." Quoting either one from a one-line brief is guessing, and guesses get paid for later — usually by the client, in the form of a rushed, corner-cut build.

Step one: the discovery questions

Before anything else, I want to understand the shape of the problem, not the solution someone already has in mind. The questions that do the most work early are:

• What does success look like in six months? A site that ranks, a tool that saves staff hours, a product that converts — the goal dictates the architecture, not the other way around.
• Who is on the other side of the screen? The public, paying customers, internal staff? That single answer reshapes auth, performance budgets, and the entire security posture.
• What already exists? A domain, a brand, content, a database, a half-finished previous attempt. I'd rather know about the legacy system on day one than discover it in week three.
• What's the real deadline, and what's driving it? "Soon" and "before our trade show on the 14th" are different projects with different tradeoffs.
• Who maintains this after launch? If the client edits content themselves, that's a requirement that changes how I build, not a detail to sort out at the end.

Step two: drawing the scope boundary

Scope is defined as much by what's out as what's in. The most valuable sentence in any plan I write is usually the one that starts with "this does not include." An unstated assumption is a future argument waiting to happen, so I make the boundary explicit and put it in writing:

IN SCOPE
  - 5 pages, responsive, from supplied content
  - contact form -> email, with spam protection
  - basic on-page SEO + sitemap

OUT OF SCOPE (separate phase)
  - content writing / copywriting
  - e-commerce / payments
  - ongoing maintenance retainer

None of this is about saying no. It's about making sure that when the client says "and obviously it'll take payments," we discover that now — while it's a pleasant conversation about a phase two — instead of at launch, when it's a crisis.

A clear scope boundary isn't a wall between me and the client. It's the thing that lets us both point at the same plan and agree we're building the same project.

Step three: writing the assumptions down

Every estimate rests on assumptions, and the difference between a professional and an amateur is whether those assumptions are written down or left implicit. I state mine plainly — content will be supplied by a certain date, third-party services have available APIs, the design is a single agreed direction rather than open-ended exploration. When an assumption turns out to be wrong, we have a shared document to point at and a calm conversation about adjusting, rather than a dispute about what was "obviously" included.

Why fixed quotes from a one-line brief fail

There's a strong temptation, especially in a competitive market, to fire back a confident number the moment someone asks. It feels responsive. It's also how projects get quietly sabotaged before they begin. A number attached to an undefined scope can only end one of two ways:

• The quote was too low, the real work surfaces mid-build, and now there's pressure to cut corners — exactly the corners, like security and testing, that don't announce themselves until something goes wrong.
• The quote was padded to cover the unknown, and the client overpays for the privilege of vagueness.

Neither serves anyone. Pricing against real scope means the number reflects the actual work, the client knows what they're getting, and nobody's incentive is misaligned at 11pm before launch.

What the client gets out of it

From the outside, scoping can look like delay — why isn't the developer just building? But the discovery conversation is the cheapest, fastest place to change your mind. Rethinking a feature in a planning doc costs a sentence. Rethinking it after it's built costs a rebuild. The hour spent defining the project up front is the highest-leverage hour in the whole engagement, and it's the reason the build phase tends to be calm instead of chaotic.

So when I don't quote a number off a single sentence, it isn't evasiveness — it's the first sign that the project is being taken seriously. The plan comes first. The price follows the plan. And the code, when it finally gets written, is building something everyone already agreed on.