← Insights · Delivery guide
How to scope a software project before development
Scope a software project before you commit budget: define outcomes, users, constraints and integrations, surface risks early, and agree what done means.
Write down the outcome, not the feature list
Begin with the change you want: fewer manual steps, a new revenue line, a faster process for a specific team. Then list the features that might deliver it. Starting from the outcome makes it easier to cut scope later without losing the reason the project exists.
Name the users and their main journeys
For each type of user, describe the few journeys they must be able to complete. These journeys become the backbone of design, estimates and testing. If a feature does not support one of them, question whether it belongs in the first release.
List integrations and constraints early
Most surprises in delivery come from systems outside the project: a payment provider, an old database, a single sign-on requirement, a compliance rule. List every system the software must talk to, who owns it and how it can be accessed. Unknowns here deserve a short technical spike before anyone commits to a date.
Make risks and assumptions explicit
Record what you are assuming about data, users, traffic and third parties, and what happens to the plan if each assumption is wrong. A good estimate states its assumptions openly. A partner who cannot tell you what would make their estimate wrong has not finished scoping.
Agree what done means
Define acceptance criteria for each journey, the quality checks a release must pass, and what is handed over at the end: code, infrastructure, documentation and access. Agreeing this before development starts prevents the most common late-project argument, which is about what was actually promised.