How custom software projects are scoped

Start with the outcome, not the feature list

A feature list says what to build. An outcome says why. "A customer portal" is a feature. "Customers can check their order status without phoning us" is an outcome. Starting from the outcome lets everyone judge whether a feature earns its place.

A good first question is: if this project works perfectly, what will be different in six months?

Separate what must exist from what would be nice

Almost every idea is bigger than its first release should be. Sorting features into three groups keeps the first version focused:

• Must have: without it the product does not do its core job
• Should have: valuable, but the product works without it on day one
• Could have: worth doing later if the first release proves out

The first release is the must-haves, built well, plus whatever should-haves fit comfortably.

Write down the users, the workflows and the data

A scope needs more than screens. It should describe who uses the product, the steps they take, and the information involved:

• The different kinds of users and what each can do
• The main workflows from start to finish, including the awkward exceptions
• The data the product stores and where it comes from
• The other systems it must connect to, such as payments, email, a CRM or an existing database

Name the assumptions and the risks

Every plan rests on assumptions: that a third-party service offers the data you need, that users will accept a particular flow, that a legacy system can be reached. Writing them down makes them visible, and the risky ones can be tested early instead of discovered late.

When something is genuinely unknown, a short, time-boxed discovery phase is cheaper than guessing and being wrong.

What a good scope document contains

It does not need to be long. It needs to be specific enough that two reasonable people would read it and picture the same product.

Plan for change

Scope will move, because you learn as you build. The goal is not to prevent change but to handle it openly: when something new comes up, say what it adds, what it costs in time or money, and what it displaces. A scope that is written down makes that conversation easy; one that lives in people's heads makes it a dispute.

How we do it

We do not start building until you have a written scope and proposal you have approved. It covers the points above, in plain language, and it is the document we both work from. If your project needs a discovery phase first, we will say so and scope that separately.