Software project scoping: what to define before you ask for quotes

Software project scoping is the work of defining the boundaries of a system before it is designed or priced: the people who use it, the jobs they do in it, the data it holds, the other systems it talks to, and the things it will not do. The output is a short written document, often called a scope of work or requirements brief, that any competent team can read and price.

Scoping is not the same as a full technical specification. You do not need to choose a database or draw every screen. You need enough detail that two different teams would picture roughly the same product. The UK government's service manual makes the same point about its discovery phase (opens in a new tab): before you commit to building, understand the problem, the users and the constraints.

If you have not yet decided whether to build at all, start with our build vs buy software guide. Scoping is still useful in that case, because the same document lets you test off-the-shelf products against your must-have list.

Scope first because a quote prices an imagined system, and without a written scope every bidder imagines a different one. A one-paragraph brief such as "a portal where customers track orders" could mean a read-only status page or a full self-service platform with returns, invoices and chat. The quotes you get back will be impossible to compare.

A written scope also protects you after the contract is signed. When a feature is in the document, it is in the price. When it is not, everyone can see that it is a change. That clarity removes most of the arguments that sour client and developer relationships halfway through a build.

Finally, writing the scope forces internal decisions early. Teams often discover during scoping that sales and operations want different things from the same system. It is far cheaper to settle that in a meeting room than in the third month of development.

A useful scope document has eight parts, and most fit on four to eight pages. Keep the language plain: write for the person who will run the business process, not for a programmer. Developers will ask follow-up questions, and their questions are a good sign that they are reading carefully.

Describe workflows as short stories from the user's point of view, not as lists of screens. A common format is the user story (opens in a new tab): "As a branch manager, I want to approve discounts above 10 percent, so that margins stay under control." Each story names a person, an action and a reason, which is exactly what a developer needs to estimate it.

For each main workflow, add what happens when things go wrong. What if the customer's credit limit is exceeded? What if stock runs out between ordering and dispatch? These exception paths often take as much effort as the happy path, and leaving them out is one of the main reasons quotes come in low and invoices come in high.

Attach examples wherever you can: a current spreadsheet, a paper form, a screenshot of the tool you use now, a sample report. Real artifacts answer dozens of questions that prose cannot, and they reveal fields and rules people forget to mention.

Rank every feature using four labels: must have, should have, could have and won't have this time. This is the MoSCoW method, and its value is that it makes you say no to things on paper before they cost money. A first release should contain the musts and nothing else.

A good test for a must is simple: if this feature were missing on launch day, would the system be unusable for its main purpose? If people could manage with a workaround for a few months, it is a should. Bidders can then price the musts as a fixed phase and the rest as options, which gives you control over budget.

For a product you plan to sell, this ranking is the heart of the plan. Our article on what a realistic SaaS MVP includes applies the same thinking to subscription products, where the temptation to add features before launch is strongest.

• Must: the system fails its main purpose without it.
• Should: important, but a temporary workaround exists.
• Could: useful polish that can wait for real user feedback.
• Won't (this time): agreed and recorded as out of scope for this release.

The requirements most often missed are the ones nobody sees on a screen: data migration, integrations, security, accessibility, reporting and who will host and maintain the system. Each can change the price significantly, so name them even if your answer is "we are not sure yet".

Security deserves a specific line. Ask bidders which security standard they test against; the OWASP Application Security Verification Standard (ASVS) is a widely used checklist for web applications. Accessibility deserves one too: if public users or staff with disabilities will use the system, refer to the W3C's WCAG guidelines. For systems that connect to others, our API design best practices guide lists what to ask about interfaces.

• Data migration: how much old data moves across, how clean it is, and who checks it.
• Integrations: each connected system, whether it has a documented API, and who holds the account.
• Roles and permissions: who may see prices, approve refunds or export customer data.
• Reports: the five or six reports managers actually read, with sample layouts.
• Languages and layout: for example English and Arabic with right-to-left screens for UAE users.
• Hosting, backups and maintenance after launch, including who pays for each.

You can run software project scoping yourself in a series of short workshops with the people who will use the system. The six steps below work for most business systems and portals, and the result is a document you can send to several developers at once.

If you would prefer a team to run it with you, a paid discovery sprint covers the same ground and adds a clickable prototype. Digihub's Discovery Sprint costs $1,200, takes about one to two weeks, ends with a written specification and a fixed quote, and its fee is credited to the build if you go ahead; details are on our custom software pricing page.

Compare the assumptions behind each quote, not just the totals. Ask every bidder to list what they included, what they excluded and what they assumed about your data and integrations. A low quote that assumes clean data and no exception handling is not cheaper; it is a different project.

Also check the pricing model. Fixed price suits a well-defined first phase, because the risk of overrun sits with the developer. Time and materials suits ongoing work where priorities change week to week. Many projects use both: a fixed-price first release, then a monthly retainer or dedicated developer for what follows.

Our web application development team prices against written scopes in fixed phases, and ownership of the custom code passes to you on full payment. Whoever you choose, insist on the same basics.

• A written list of inclusions, exclusions and assumptions.
• Milestones tied to working software you can test, not just to dates.
• Clear terms on code ownership, repository access and hosting accounts.
• A defined warranty period for fixes after go-live and the cost of support after it.
• How change requests are estimated and approved.