How to Scope a Web Project (Without Getting Burned)

Scope creep kills web projects. In our experience at Gravtek, 80% of projects that go over budget do so not because the work was underestimated — but because the scope was never clearly defined in the first place.

Here is the scoping process we use with every client.

Step 1: Define the goal, not the solution

Most clients come to us with a solution in mind. "I need a website with a contact form, a blog, and a product catalogue." What we want to understand first is the goal: "I need to generate 20 qualified leads per month and establish credibility with enterprise buyers."

The goal shapes everything. Once you know the goal, you can evaluate whether each proposed feature actually serves it — or just adds cost and complexity.

Step 2: Map the user journey

Before wireframes or components, we map the key user journeys. Who are the users? What are they trying to do? What is the path they take from first visit to conversion?

This mapping often reveals that some requested features are redundant, and some missing features are critical. It is far cheaper to catch this at the scoping stage than mid-build.

Step 3: Write a feature list with acceptance criteria

Every feature gets a brief acceptance criteria statement: a plain-English description of what "done" looks like. For example:

• ·Contact form: User can submit name, email, and message. Submission sends an email notification to the business owner. User sees a success confirmation. Fails gracefully if the email service is unavailable.

This stops ambiguity from accumulating. When there is a question about whether something is in scope, you refer to the acceptance criteria.

Step 4: Estimate with ranges, not point estimates

We give timeline estimates as ranges (e.g., 3–5 weeks) rather than fixed dates. Why? Because software development involves real uncertainty. A range is honest about that uncertainty. A fixed target date that is later missed is a trust problem.

We explain what could push the estimate toward the higher end (complex integrations, content migration, third-party API dependencies) and what could reduce it (simpler design requirements, pre-existing brand assets).

Step 5: Write a scope document and sign off

Once we have alignment on goals, user journeys, features, and estimates, we write a scope document. Both parties sign off. This is not bureaucracy — it is protection for the client and the agency.

When a new request comes in during the build, we can evaluate it clearly: is it in scope? If not, how does it affect the timeline and what needs to be deprioritized?

The result

Projects scoped this way run more smoothly, finish closer to estimate, and leave both sides feeling good. The upfront conversation takes time — but it saves much more time than it costs.

If you have a project you are trying to scope and are not sure where to start, get in touch. We offer a free initial scoping call.