Discovery phase in software development: what the client should sign off

Published 18 October 2026

The discovery phase is the stage before a software project where the agency and the client work out what will be built, for whom, and at what cost — before anyone commits to the build. It ends with a set of documents the client signs off. Those documents are what the estimate, the contract and every later change get measured against, so what they say, and which version was signed, matters more than how polished they look.

Proper discovery is really proper scoping. You don’t get it right, you start off at disadvantage.

— r/agency, June 2026

What is the discovery phase in software development?

Discovery turns an idea into something that can be estimated and agreed: the business goal, the users, what is in and out of scope, the main flows, the technical approach, the risks, and the cost. Its length depends on how much is unknown — days for a small website, weeks for a platform with integrations and several kinds of users.

Some agencies sell it as a paid stage of its own. One describes the pitch: “the client doesn’t know how much their job will cost and the only way to get an accurate quote is have someone spend the time to estimate is properly. We explore all their technology options, scope each feature and list out how we’ll build their thing” — priced as a share of the full job, and “fully refundable if they sign on” (r/agency, December 2024).

Discovery vs requirements gathering: discovery decides whether and what to build, and ends with a decision and an estimate. Requirements gathering details what was decided, and ends with a specification. Discovery produces the first version of the requirements; the functional specification grows from it.

Discovery phase deliverables

Do not skip the last two: they are what every later change is measured against.

The discovery sign-off

The deliverables are signed together, as one set, with their versions named. Copy it and fill in the square brackets:

DISCOVERY SIGN-OFF

Project:          [project name]
Discovery ran:    [from date] to [to date]

DOCUMENTS IN THIS SIGN-OFF
  Project brief             version [x.y]
  Scope: in and out         version [x.y]
  User flows / prototype    version [x.y],
                            [link]
  Requirements              version [x.y]
  Technical approach        version [x.y]
  Risks and assumptions     version [x.y]
  Estimate and roadmap      version [x.y]

WHAT THIS SIGN-OFF MEANS
  - The estimate and the roadmap are based
    on the documents above, at the
    versions above.
  - Anything not listed under "in scope"
    is a change request, priced and
    approved before work starts.
  - An assumption that proves false is
    reviewed together, with its effect on
    cost and dates.

DECISION
(one block per person)
  Name:      [   ]
  Role:      [   ]
  Decision:  [approved / approved with
             comments / rejected]
  Date:      [   ]

The requirements sign-off template has the email that asks for it.

Questions to ask during the discovery phase

The essentials are below; the full list by topic, with an interview template, is in requirements gathering questions.

The business

• What problem does this solve, and for whom? What happens if it is not built?
• How will you know it worked? Which number moves?
• Is there a date that cannot move, and why?

The users

• Who uses it, and how often? Who uses it least willingly?
• What do they use today instead?

The scope

• What is the smallest version worth launching?
• What are you assuming is included that we have not discussed? (Ask for the out-of-scope list out loud.)
• Which existing systems does it have to talk to, and who owns them?

The decisions

• Who decides on scope, and who signs off? Is anyone senior who has not seen it yet?
• How will changes be asked for once the work starts?

A consultant on why the listening matters: “Just listening to a client during a discovery phase go on and on and on and then saying it back to them causes all kinds of things to fall into place” (Hacker News, 2024).

Why discovery goes wrong

A discovery can be done, paid for and still fail the project. One client’s account:

We had a consulting company come in and do an entire paid discovery & project planning phase. They came back with a proposal for phase 1, which they overran by 100%. The entire project ended in acrimony since it was a statement of work, not time & materials … Change requests, threats of litigation, meticulous reading of specs to see what we could try to wring out of them let us with a product that never went to production.

— Hacker News, 2023

The usual causes:

• The estimate is not tied to the documents. When the scope moves, nobody can show what the original price covered.
• The out-of-scope list was never written, so each side fills the gap with what it assumed.
• Assumptions stay in people’s heads instead of in the sign-off.
• The sign-off names no version, so the documents keep changing after it.
• The scope review is light. “If the original scope review was lightweight, you have no baseline to point to” (r/agency, 2026).

What follows is scope creep, and the arguments that come with it.

What comes after the discovery phase

1. Sign-off on the deliverables, as one versioned set — the business part can be a business requirements document.
2. The contract or statement of work, referring to that set.
3. Detailed requirements for the first release — the functional specification and its acceptance criteria.
4. Design and build. Every change to the signed set goes through a change request.

Where Specroot fits

This is the problem Specroot works on: discovery deliverables signed off as one version, which stay the baseline every later change is measured against. Specroot for agencies and consultancies.