How to scope a build before you pay for it

The short answer

Scoping a software project is the work of writing down what will be built, for whom, against which systems and at what risk, in enough detail that one price can be put on it and defended. It is the thing that makes a fixed price possible, and it is the only document that later decides what counts as a defect and what counts as a change.

We sell builds, so we have an interest in you thinking scoping is worth paying for. That is worth knowing before you read the rest, and it is why the sections below quote the evidence that argues against us as well as the evidence that helps.

Every page currently ranking for this question explains how to write a scope. None of them says what scoping costs, who pays for it, or who owns the document if you walk away. Those are the three questions a buyer actually has, so they are what this guide is about.

What a scope document actually contains

There is a published international standard for this, and almost nobody uses it. BS ISO/IEC/IEEE 29148:2018 “specifies the required contents of the required information items” that requirements work produces9.

The full text is behind a paywall and we have not read it, which is the honest position and also the useful one: you can ask a supplier which parts of it their document covers, and the answer tells you something.

The best-known free-standing template is Volere, whose last numbered section is 27 and whose complete version, in its own words, “runs to 90 pages”10. It is thorough in a way that a two-week document is not, and pretending otherwise would be silly. What a short scope has to carry is narrower.

• The workflow, end to endWhat happens now, who touches it, and where it breaks. Not the features. The process, written down in the order it actually runs.
• The users and what each may doNamed roles with named permissions. This is where most of the argument about cost lives, because roles multiply screens.
• Every system it has to talk toWhich ones, in which direction, through whose API, and what happens when one of them is down. An integration nobody named is the commonest reason a fixed price moves.
• The data, and where it comes fromWhat is held, what is migrated, what is left behind, and who signs off that the migrated version is right.
• The risks, named and ownedThe things that could make this take longer, each with the person who can clear it. A risk with no owner is a delay with no date.
• What is explicitly not includedThe list that matters most, and the one most often missing. Anything not on the in-scope list should be on this one, by name.

A document with those six things can carry a price. A document with a feature list and a timeline cannot, because it does not say what happens when reality differs from it.

What scoping costs, and what free really means

Most pages answering this quote a range and cite nothing. There is a better source. A supplier that wants to sell to the public sector through the G-Cloud framework has to publish its price in a catalogue anyone can read, so the discovery services filed there are real prices rather than marketing ranges.

The labour arithmetic agrees with them, which is the useful cross-check. Median UK contract day rates, from advertised vacancies in the six months to 7 September 2026: business analyst £500, technical architect £600, senior software engineer £5258. Two of those people for ten working days is £10,000 to £12,000 before anyone has written a line of code.

So a supplier offering that free is doing one of three things: something much smaller than a scope, something they intend to recover inside the build price, or speculative work in the hope of winning. All three can be legitimate. Knowing which one you are in is the point.

On speculative work, the design profession has thought about this longer than software has. AIGA publishes a letter for designers to send clients who ask for work on spec, and it puts the objection plainly: “There are few professions where all possible candidates are asked to do the work first, allowing the buyer to choose which one to compensate for their efforts.”22

Its analogy is the one to keep: “Just consider the response if you were to ask a dozen lawyers to write a brief for you, from which you would then choose which one to pay”22. It is American and it is about graphic design, and the point still lands. A free scope is spec work, and somebody pays for it.

One honest note on duration. GOV.UK’s service manual says of a discovery that “There’s no set time period for a discovery, but around 4 to 8 weeks is typical”7, and suppliers filing against that standard say the same3.

Our own scoping is one to two weeks, and that is not because we are cleverer. It is a smaller job: a scope for one workflow at a 200-person firm is not a discovery for a national service.

Four ways suppliers handle it, and what each one costs you

There are four models in the market. None is dishonest by itself. What matters is knowing which one you are in, because they transfer risk in different directions.

The two questions to ask about a paid discovery are both answered in public by the suppliers who use that model, which is the fastest way to see what a fair answer looks like.

Rocking Tech publishes a three-week platform discovery sprint at “£4,500 + VAT” and states the terms on the same page: “Credited in full against build cost. Proceed with a Custom Platform Build within 30 days and your £4,500 is applied to the total. If not”, it says, “the report is yours. Take it to any developer you like.”5

Foresight Mobile publishes a four-week engagement at £3,500 with the same shape: “If you decide not to proceed, or to build with a different partner, you keep all deliverables. The Gameplan is yours.”6

Foresight also publishes the number almost nobody does, which is what the work costs you rather than what it costs: “Total client time commitment: 5-7 hours across 4 weeks”6. Worth asking for. A discovery that needs thirty hours of your operations manager is a different proposition from one that needs five, and only one of those numbers is usually on the proposal.

Who owns the scope you paid for

Under UK law the person who wrote the document owns the copyright in it, not the person who paid for it, unless the contract says otherwise. This is the question no competing page answers and the one most likely to cost a buyer real money.

The Copyright, Designs and Patents Act 1988 is explicit: “The author of a work is the first owner of any copyright in it”11.

The Intellectual Property Office spells out what that means when you commission something: “the first legal owner of copyright is the person or organisation that created the work and not you the commissioner, unless you otherwise agree it in writing”12.

Where nothing is agreed, a court may be willing to find an implied licence, and then, in the office’s words, “the commissioner of the work may only get a limited non-exclusive licence”12. Permission to use a document for the purpose it was commissioned for is not the same as owning it.

It is a normal thing to ask, and the suppliers who have thought about it answer it in public. Asked “Can I take the report to another developer?”, Rocking Tech’s own page says: “Yes. It’s yours. The deliverable is designed to be portable, any competent development team can use it as a brief.”5

Foresight Mobile says the same of its document: “You can take it to any development partner, whether that’s another agency, an internal team, or offshore developers.”6 If a supplier cannot match that, the reason is worth hearing.

The Cabinet Office adds the distinction that actually matters in practice, which is that ownership is often the wrong thing to argue about: “the right to use IP is often more important than ownership, and a party can have a licence to use IP even if they do not own it”13.

So the question to ask is not only “do I own it” but “what am I allowed to do with it, and when”.

We are not lawyers and this is not advice. The two documents above are the primary sources and both are free to read.

A UK commercial firm writing about software agreements lists the four questions an agreement has to settle: who owns the rights, what licences the project needs, what third-party licences are required, and whether the client may modify the source23. Those are good questions to take into a first meeting.

Fixed price or day rate: what each one moves

A fixed price does not abolish risk. It decides which of scope, time and cost is allowed to move, and the honest argument for scoping first is that it is the only way to earn the right to fix the price at all.

The Cabinet Office puts the trade plainly. In a waterfall shape “the desired scope must be delivered. The consequence of pursuing this is that time and cost can vary.” In an agile shape, delivery “constrains the time and cost available”, which “means that the scope becomes the variable”14.

The same guidance says something that cuts against our own model, and it is right: “Those projects with very limited information and a greater level of uncertainty are less likely to achieve the intended outcomes if they use a rigid fixed-price model”14.

We agree. That is the argument for removing the uncertainty before the price is set, not for pretending it is absent. If a supplier will fix a price before anyone has written the scope down, ask what they have padded it with.

Its own remedy is the shape this guide is describing. It recommends that “any initial work during ‘discovery’ is contracted for on a T&M basis so that the provider is able to scope the requirement and give a more accurate cost that is based on an improved understanding of the scale and complexity of the project”14.

After that, it says, the parties should move to a more structured model. Scope first, price second.

It also describes the two failure modes buyers recognise: either a perfect specification whose time and cost to agree “is often significant, for both parties”, or a contract entered into with an imperfect one “which results in change requests to manage time, overruns or scope reductions which do not manifest themselves until much later”14. Most buyers have met the second.

What the evidence says, including the parts against us

The two statistics a supplier would most like to quote at you here are both unsafe, and we are not going to use them. Saying why is more useful than either would have been.

The first is the claim that a problem caught during scoping is many times cheaper than one caught later. The largest test of it, 171 projects between 2006 and 2014, reports: “We found no evidence for the delayed issue effect; i.e. the effort to resolve issues in a later phase was not consistently or substantially greater than when issues were resolved soon after their introduction”15.

It is the most convenient argument available to a firm that sells scoping, and it does not survive testing, so it does not appear on this page.

The second is the Standish CHAOS figure, usually quoted as 31% of projects failing. Its 1994 numbers cannot be read at source: the report is not publicly available, and the current one, CHAOS Report: Beyond Infinity, sells for $450 on Standish’s own store17.

When researchers applied Standish’s own definitions to 5,457 forecasts across 1,211 real projects, they concluded that those definitions “are misleading, one-sided, pervert the estimation practice, and result in meaningless figures”16.

They also print the reply they got from Standish’s chairman: “All data and information in the Chaos reports and all Standish reports should be considered Standish opinion and the reader bears all risk in the use of this opinion.”16

What the evidence does support is narrower and still worth having. Scope creep is real and measured: a professional body’s 2018 survey of over 5,000 professionals found 52% of projects in the previous year experienced it, “a significant increase from 43% reported five years ago”20.

The UK’s public auditor, reviewing major programmes, put scope first in its list of four root causes21. Neither says a scope document prevents failure. Both say that not knowing what you are building is where the trouble starts.

How to tell a scope from a sales document

The test is not length or polish. It is whether the document would settle an argument six weeks from now, when you say something is broken and the supplier says it was never in scope.

One more thing that is worth conceding. A scope does not stop requirements changing, and any supplier who says it does is selling something. What it does is turn each change into a decision with a price on it, before the work, rather than an argument afterwards.

The blueprint, as one worked answer

Our version is called the blueprint, and it sits in the fourth model above: we do not sell it separately. It is the first one to two weeks of a build and it is inside the build’s price. It ends in the written scope, a clickable prototype and one price, and that price is what you commit to. Nothing is built before it.

The obvious objection to this model is that you engage before the final number exists. The answers are that the bands are published in advance so you know the range you are in, that the price is settled before anything is built, and that the scoping is what turns the band into the number.

The pricing page carries the bands, and what moves a build between them is in the cost guide.

When not to scope, and when not to build

Small, well-defined, familiar work does not need a discovery and should not be sold one. If a supplier can price it by looking at it, let them.

• The work is a known shape. A form, a fix, a report against data that already exists. There is nothing to discover, so paying to discover it is waste.
• A product already does it. Some scoping calls should end in the name of a piece of software and no invoice. Ours do, regularly.
• The appetite is below the floor. If what you want is smaller than a supplier’s minimum, a good freelancer will do it for less, and a supplier who says so is worth remembering.
• Nobody inside the business owns it. Without a decision-maker, scoping produces a document that nobody acts on. Fix that first.

Questions people ask about scoping