DEV Community: Oleksandr Tytarenko

How to scope a software project: a step-by-step guide

Oleksandr Tytarenko — Mon, 12 Oct 2026 08:01:35 +0000

To scope a software project, start from the goals, list the users and what they need, turn that into prioritised requirements, and then write down explicitly what is in, what is out and what comes later. Estimate the in-scope work as a range with its assumptions, and get one decision maker to sign the result. The seven steps below follow that order; the in, out and later list in step 5 is the artifact that does most of the work.

What scope is, and what scope creep is

Scope is the agreed list of what the project will deliver, and just as importantly, what it will not. It is not the same as the requirements: requirements describe what the product must do, while scope sets the boundary of this particular piece of work, usually one release.

Scope creep is what happens without that boundary. The PMI defines it as the uncontrolled expansion of project or product scope without matching changes to time, cost and resources (PMI, Scope and stakeholder management). The key word is uncontrolled: scope can change, and often should, but each change needs a visible decision about what it costs and what moves out.

Scoping well is mostly done during the discovery phase. If you want the wider context, see what a discovery phase is in software development.

Step 1-2: goals and users

Step 1: Write two or three goals with numbers

Everything else is judged against the goals, so start there. A goal says what changes for the business or the user, with a metric, today's value, a target and a date. "Improve onboarding" is not a goal; "cut the time from sign-up to first invoice from 3 days to 1 day by June" is.

Ask the decision maker to rank the goals. When two features compete for the same week, the ranking decides.

Step 2: List the users and what they are trying to do

Name each type of user (and each external system the product talks to) and the main job they need to get done. Then walk through the main journey of each, step by step, and mark where it goes wrong today. Talk to people who will use the product, not only to the people who pay for it.

This step catches the most expensive scope gaps: the admin role nobody mentioned, the approval step that exists only in one manager's head, the data import that has to happen before anyone can use the product at all.

Step 3-4: requirements and priorities

Step 3: Turn needs into testable requirements

For each journey, write what the product must do as short, testable requirements: one behaviour each, with acceptance criteria someone else can check. Separate three kinds:

Functional: what the product does ("a dispatcher can reassign a job").
Non-functional: how well it does it ("the job list loads within 2 seconds").
Constraints: what cannot change ("data stays in the EU", "must use the client's existing login").

Link every requirement to a goal. A requirement with no goal behind it is the first candidate for "later".

Step 4: Prioritise with MoSCoW

Mark each requirement Must, Should, Could or Won't (this time). The test for a Must is blunt: would the release be useless, illegal or unsafe without it? If not, it is a Should.

Keep the Musts in proportion. The DSDM guidance from the Agile Business Consortium recommends that Must Have work stay at no more than about 60% of the effort, leaving the Shoulds and Coulds as room to absorb surprises. If almost everything is a Must, the priorities have not been set yet.

Step 5: in, out and later

This is the step that prevents most scope arguments. Take the prioritised list and sort every item into one of three columns, then write the result down as its own short section of the scope document.

In (this release)	Out (not this project)	Later (a known next step)
All Musts	Things you decided not to build at all	Shoulds and Coulds that did not fit
Shoulds that fit the budget	Ideas that do not serve a goal	Features waiting on a dependency or a decision
Constraints, always	Work someone else owns (another team, the client)	Second user types or markets

A few rules make the list useful:

Write the "out" column in full sentences. "No native mobile app; the web app works on mobile browsers" is clearer than "mobile: out".
Give "later" items a trigger, such as "after the pilot" or "once the payment provider is chosen", so they do not read as forgotten.
Name who owns anything outside the team: data migration, content, third-party contracts, user training.
Review the list with the decision maker line by line. Silence is not agreement.

The "out" column is the one people skip, and the one they need most when a new request arrives in week six: you can point at it and ask what should move to make room.

Step 6: estimate as a range

Estimate only the "in" column, and give a range rather than a single number. Early estimates are genuinely uncertain: in Steve McConnell's Cone of Uncertainty, an estimate made at the initial concept stage can be off by up to 4x in either direction, narrowing as requirements and design are completed (Construx). A single number hides that; a range shows it.

A practical way to do it:

Group the in-scope requirements into milestones that each deliver something a user can see.
Estimate each milestone as low-high effort, for example in person-weeks.
Write the assumptions each estimate relies on ("the dispatch system's API is documented and available in test", "the client supplies content by week 4").
List the main risks and what you would do if one happens.

The assumptions are part of the estimate, not a footnote. When one turns out to be false, the estimate is expected to change, and everyone can see why.

Here is what that looks like in the public example report, for an invented project called Fieldwise: four milestones, each with a person-week range, a total of 16-22 person-weeks, and the assumptions listed right under them.

Step 7: get the scope signed

The final scope statement can be short. It should contain:

The goals and their metrics.
The users and the journeys covered.
The in-scope requirements, or a reference to the requirements document.
The in, out and later list.
The estimate range, milestones and assumptions.
How changes will be handled: who can request one, who approves it, and how its cost is shown.

Ask the person who owns the budget to sign it, not only a project contact. For client work, the signed scope usually becomes the basis of the statement of work or the contract; that wording is a matter for the contract itself (and for a lawyer where needed).

Before you ask for the signature, run the scope through the discovery phase checklist: an unanswered question there is a risk you can still fix cheaply.

If you keep the scope in one place rather than across files, it is also easier to keep current. In Discovery Phase AI, for example, requirements carry their MoSCoW priority and linked goal, and the roadmap stage holds milestones with a low-high person-week estimate next to the assumptions they depend on; the example report shows the whole invented project in that form.

Disclosure and a sample

I build Discovery Phase AI, a tool aimed at the writing-and-assembling side of discovery: it drafts the early stages from the decks, documents and call transcripts you already have, and exports one report. Your team still runs the interviews, reviews every draft and makes the decisions.

If you just want to see what a finished discovery looks like, here is a complete sample report for an invented field-service app. No signup needed.

The original of this post is on our blog. Questions or corrections are welcome in the comments.

This post was drafted with AI assistance and edited by a human before publishing.

Software requirements document template (with example)

Oleksandr Tytarenko — Sun, 11 Oct 2026 08:01:01 +0000

A software requirements document needs eight parts: purpose and scope, goals, users, functional requirements, non-functional requirements, constraints, assumptions and open questions, and a change log. Below is a skeleton you can paste into your own editor, with one line on what belongs in each section, a short filled-in example from an invented project, and the rules that make each requirement testable. If you are writing it at the end of a discovery phase in software development, most of the inputs already exist; this template turns them into one document the team can build and test against.

What goes in a requirements document

A requirements document answers one question: what must the software do, and how will we know it does? It is not a design document or a project plan, so it does not pick a database (unless that is a fixed constraint) or set release dates. A useful one contains:

Context: why the project exists and what is in and out of scope.
Goals: the outcomes the software must move, with a number for each where possible.
Users: who uses the system and what they are trying to get done.
Requirements: what the system must do (functional), how well it must do it (non-functional) and the limits nobody on the team can change (constraints).
Acceptance criteria: how each requirement will be checked.
Assumptions and open questions: what you believe but have not confirmed, and what is still undecided.
History: what changed, when and why.

The international standard behind the formal version, the software requirements specification (SRS), is ISO/IEC/IEEE 29148:2018, "Requirements engineering". You do not need it to write a good document, but it is the reference if a client or a regulated industry asks for a formal SRS.

The template, section by section

Copy the skeleton below into a document or a wiki page. The line under each heading says what to write there; replace it with your content.

# [Project name]: Software Requirements

Version: 0.1 | Status: Draft | Owner: [name] | Last updated: [date]

## 1. Purpose and scope
One paragraph: the problem, who has it, and what this software changes.
In scope: [bullet list]. Out of scope: [bullet list].

## 2. Goals and success metrics
Each goal with a metric, its current value, a target and a date.

## 3. Users and stakeholders
Each user type: role, what they need to get done, current pain points.
Each stakeholder: name, role, what they decide or approve.

## 4. Functional requirements
One row per requirement:
ID | Title | Description | Priority (Must/Should/Could/Won't)
| Status (Draft/In review/Approved) | Linked goal | Owner
| Acceptance criteria (one checkable statement per line)

## 5. Non-functional requirements
Performance, availability, security, privacy, accessibility,
offline behaviour, supported devices. Same row format, with a number.

## 6. Constraints
Limits the team cannot change: regulation, contracts, budget,
deadline, mandated technology or hosting region.

## 7. Assumptions
What you treat as true but have not confirmed. One line each.

## 8. Open questions
Question | Who answers it | Needed by [date] | Requirements affected

## 9. Glossary
Terms that mean something specific in this project.

## 10. Change log
Version | Date | Author | What changed and why

A few notes on using it:

Keep the ID stable. Number requirements once (REQ-001, REQ-002) and never reuse a number. Tests, tickets and estimates will point at those IDs.
Put constraints in their own section, so they are not traded away like features in a planning meeting.
Write short rather than empty. "No accessibility requirements beyond the platform defaults, confirmed with [name]" is a decision; a blank section is a question nobody asked.

If you also need the material that feeds this document (stakeholders, problem statement, architecture notes, roadmap), the discovery phase template lists every section of the wider discovery output.

A filled-in example

The example below is from Fieldwise, an invented project: a mobile app for the field technicians of an invented company, Northline Services, which today assigns visits by phone and spreadsheet and collects results on paper. The full example, with goals, journeys, architecture decisions, a roadmap and risks, is on the example report page.

Purpose and scope (excerpt). Technicians close visits on paper and the office re-types the forms into the dispatch system. In scope: a technician app and a dispatcher board connected to the existing dispatch system. Out of scope for the first release: route optimisation.

Goals (excerpt).

Goal	Metric	Current	Target
Reduce missed and repeated visits	Visits missed or repeated	9%	4%
Remove double entry	Office re-typing time per day	4 h	30 min
Technicians adopt the app	Visits closed in the app (pilot regions)	0%	90%

Requirements (excerpt).

ID	Requirement	Type	Priority	Status	Linked goal	Acceptance criteria
REQ-001	Day list: a technician sees their assigned visits for the day, in order, with status	Functional	Must	Approved	Reduce missed and repeated visits	A visit assigned in dispatch appears in the app within one minute. Visits are ordered by planned time.
REQ-003	Work without coverage: the app works for a whole day offline and synchronises when coverage returns	Non-functional	Must	In review	Technicians adopt the app	100 visits closed offline are all delivered, none lost or duplicated. The app shows what is waiting to sync.
REQ-004	Decline with a reason: a technician can decline an assigned visit and choose a reason	Functional	Should	Approved	Reduce missed and repeated visits	The dispatcher is alerted within 30 seconds. The visit returns to the board with the reason.
REQ-005	Data stays in the EU: personal customer data is stored and processed only in the EU region	Constraint	Must	Approved	none	The database and backups are hosted in the EU. No personal data is sent to a service outside the EU.
REQ-012	Routing suggestions: the app suggests an order for the day's visits that reduces driving	Functional	Could	Draft	none	Deferred to a later release after the pilot.

Assumption (excerpt). A photo is at most 5 MB and a visit has at most six photos.

Open question (excerpt). Is a ticked box enough as customer confirmation, or must the signature be legally binding? This blocks REQ-007 (customer confirmation), which stays in Draft until legal answers.

Note what is missing: screen layouts, technology choices (apart from the hosting region, a client-imposed constraint) and dates. Those belong in the design, architecture and roadmap.

Writing requirements that can be tested

A requirement is finished when someone who was not in the meeting can tell whether the software meets it. That usually takes three things: one behaviour per requirement, a measurable condition, and acceptance criteria.

Weak and strong wording

Weak	Why it fails	Testable
The app should be fast.	"Fast" means something different to everyone.	The day list opens in under two seconds on the reference phone with 20 visits.
The system must handle offline mode properly.	"Properly" cannot be checked.	100 visits closed offline are all delivered after reconnecting, none lost or duplicated.
Users can manage visits.	"Manage" hides several behaviours.	Split into: view the day list, close a visit, decline a visit with a reason.
The app is user-friendly.	Not observable.	Closing a visit takes under two minutes in the pilot test.

Words to search for and replace before review: fast, easy, intuitive, user-friendly, flexible, robust, properly, etc., and/or, as appropriate, support. Each one usually hides a number or a second requirement.

Acceptance criteria

Acceptance criteria are the checks that decide whether a requirement is done. Write them as short statements that are either true or false, one per line, from the user's or system's point of view. They become the basis of acceptance tests, so a tester should be able to read one and know what to try.

Two to four criteria per requirement is typical. Ten usually means several requirements; none means it is not understood yet, so move it to open questions.

MoSCoW priority

MoSCoW sorts requirements into four groups:

Must: without it the release does not work, is not legal or is not safe.
Should: important, but the release still works without it, perhaps with a workaround.
Could: useful if time allows; the first to drop when the schedule is under pressure.
Won't (this time): agreed to be out of this release. Writing it down is the point: it records a decision instead of leaving the request in limbo.

The method comes from the DSDM agile framework (background on the MoSCoW method). A common rule of thumb is that Musts should take no more than about 60% of the planned effort, so the Shoulds and Coulds act as contingency. That is a practitioner guideline, but the point holds: if everything is a Must, priority carries no information.

Non-functional requirements

Non-functional requirements describe qualities of the whole system rather than one feature. They are often left empty, and they cause late surprises because they drive architecture and hosting choices. Areas to ask about:

Area	Question to answer	Example of a measurable answer
Performance	How quickly must key screens or calls respond, under what load?	Day list opens in under 2 s on a three-year-old phone
Availability	When must it be up, and how much downtime is acceptable?	Available 06:00-20:00 local time on working days
Offline and connectivity	What must work without a network?	A full day of visits can be closed offline
Security	Who can sign in, how, and what happens to a lost device?	Sign-in through the company directory; a lost phone can be locked remotely
Privacy and data location	Where may personal data be stored and processed?	Only in the EU region, backups included
Accessibility	Which standard or level applies?	Name the standard and level the client requires
Supported platforms	Which devices, browsers and versions?	Android and iOS versions in use across the fleet

Write each answer in the same row format as functional requirements, with an ID, a priority and acceptance criteria. "Secure" is not a requirement; "a lost phone can be locked from the office" is.

Keeping the document alive

Three habits keep the document from going stale after sign-off.

Versioning. Give the document a version and a status (Draft, In review, Approved), give each requirement its own status, and log every change with its reason. When the team disagrees about what was agreed, the log settles it.

Traceability to goals. Link every requirement to the goal it serves, and check the other direction too: every goal should be served by at least one requirement. A requirement with no goal is a constraint, a quality, or scope creep worth questioning; a goal with no requirements will not be delivered. Carry the requirement IDs forward into tickets, test cases and milestones so you can answer "what breaks if we drop REQ-004?".

Change control. After approval, every change records who asked, which requirements change, what it does to the estimate and who approved it. On a small project that is a line in the change log and a message to the sponsor; what matters is that nobody edits an approved requirement silently.

Tools can take over the first draft. Discovery Phase AI drafts requirements (type, MoSCoW priority, acceptance criteria and a linked goal) from the decks, documents and transcripts you upload, for you to review before anything is saved, and gives each requirement an AI quality score.

Which format: PRD, BRD or SRS

The three names overlap, and many teams use one document for all three jobs. The difference is mostly who the document is for:

Document	Main reader	Focus	When it is the right shape
BRD (business requirements document)	Sponsors, business owners	Business problem, objectives, scope, benefits	Getting a project approved and funded, before a solution is chosen
PRD (product requirements document)	Product, design and engineering	What the product does for its users, features, user flows, release scope	A product team building and iterating on its own product
SRS (software requirements specification)	Engineering, testing, the client or a supplier	Precise functional and non-functional requirements, acceptance criteria, constraints	A contract or handover between parties, regulated work, or anything that will be formally tested against the document

The template above is an SRS with a short business section on top, which suits most client projects: the sponsor reads sections 1 and 2, the delivery team works from sections 4 to 8. An internal product team can drop the formality and keep goals, requirements and acceptance criteria. For a tender or a regulated domain, check whether the client expects the ISO/IEC/IEEE 29148 structure.

FAQ

How long should a software requirements document be?

As long as the requirements, no longer. The Fieldwise example has 12 requirements; a larger system can have hundreds. What matters is that each one is testable and traceable to a goal or a constraint.

Should user stories replace the requirements document?

They can sit inside it. A user story ("As a technician, I want to decline a visit with a reason so that dispatch can reassign it") is one way to phrase a functional requirement, and its acceptance criteria are the same. What stories often miss are non-functional requirements and constraints, so keep sections 5 and 6 even if the functional section is a list of stories.

When is a requirements document finished?

When every Must and Should has acceptance criteria, every open question has an owner and a date, and the sponsor has approved the version you will estimate against. After that it is maintained, not finished. Before signing off, the discovery phase checklist has a short list of checks for the requirements section.

Disclosure and a sample

If you just want to see what a finished discovery looks like, here is a complete sample report for an invented field-service app. No signup needed.

The original of this post is on our blog. Questions or corrections are welcome in the comments.

This post was drafted with AI assistance and edited by a human before publishing.

Discovery phase in software development: steps, deliverables, cost

Oleksandr Tytarenko — Sat, 10 Oct 2026 08:13:02 +0000

A discovery phase is the short stage at the start of a software project, before design and development, in which the client and the delivery team agree what problem they are solving, for whom, what the product must do and whether it can be built within the budget. It usually takes two to eight weeks. It ends with a written set of deliverables (goals, requirements, architecture, wireframes, a roadmap with ranged estimates and a risk list) and a decision: build, build something smaller, or stop.

This guide covers the steps in order, who takes part, the ten deliverables, week-by-week plans, how long it takes, what it costs, and how to read a discovery proposal before you sign one.

Discovery phase at a glance

Most discoveries follow the same sequence, even when the names differ. Each step answers one question and leaves something on paper.

Step	Question it answers	What you have at the end
1. Frame	Why are we doing this, and who decides?	Stakeholder list, background, first problem statement
2. Research	Who has the problem, and how is the work done today?	Interview notes, users and actors, current journeys
3. Goals and scope	What does success look like, and what is out?	Goals with metrics, an in/out scope list
4. Requirements	What must the product do?	Prioritized, testable requirements
5. Technical exploration	Can it be built, and on what?	Architecture diagrams, integration list, decision records
6. Screens	What will people actually see?	Wireframes of the key screens
7. Plan and estimate	How long, how much, and what could go wrong?	Milestones with low-high estimates, assumptions, risks
8. Decide	Build, change course or stop?	Executive summary and a signed-off first-release scope

What a discovery phase is (and what it is not)

A discovery phase is a time-boxed piece of work with a fixed end and a decision at that end. Its job is to reduce the biggest unknowns while they are still cheap to change: on paper, not in code. The UK government's Service Manual puts it plainly: discovery is about understanding the problem before you commit to building anything, and you should not start building the service during it (GOV.UK Service Manual). Nielsen Norman Group defines it from the design side as researching the problem space, framing the problems to be solved and gathering enough evidence to decide what to do next (NN/g).

The word "discovery" is used for several different things, and they are easy to mix up:

Product discovery is the ongoing habit of a product team deciding what to build next, through user research and experiments. It never ends. A discovery phase is a one-off project stage with a deadline.
Inception (a term common in agile consultancies) is usually a short, workshop-heavy kickoff that aligns a team on vision, scope and a first backlog. It overlaps heavily with discovery; a long inception is a discovery by another name.
Scoping is narrower: deciding what is in and out and pricing it. It is one output of discovery, often the input to a statement of work.
Legal e-discovery is the exchange of electronic evidence in a lawsuit and has nothing to do with software projects.

What a discovery phase is not: a sales meeting, a free estimate, a design sprint that ends with polished mockups, or a 100-page specification. If it does not end with a decision and a scope that the people paying for the build agree with, it has not done its job.

Why a discovery phase matters

Early in a project, nobody knows enough to estimate it well. Steve McConnell's "cone of uncertainty" describes this: at the initial-concept stage, a software estimate can plausibly be off by a factor of four in either direction, and the range narrows only as requirements and design decisions are actually made (Construx white paper). The cone is a best case, and time alone does not narrow it; decisions do. A discovery phase is where those first decisions get made on purpose instead of by accident halfway through the build.

In practice, a good discovery gives you four things:

A shared problem. The sponsor, the users and the team describe the same problem in the same words.
A scope you can price. Requirements are specific enough that two vendors would estimate roughly the same thing.
Known risks. Integrations, data, compliance and adoption risks are named, with an owner, before money is committed.
A cheap exit. If the idea does not hold up, you learn it after a few weeks instead of after a few months of development.

The last point is underrated. A discovery that ends with "do not build this yet" has saved money, not wasted it.

The steps of a discovery phase, in order

The steps overlap in real projects, and later ones often send you back to earlier ones. The order still matters: requirements written before the problem is agreed tend to describe someone's favourite solution.

1. Frame the problem and the decision

Start with the decision the discovery must support ("build a first release for two regions or not") and the people who will make it. Collect what already exists: decks, earlier specs, support tickets, analytics, contracts with current vendors. Write a first problem statement and list the hard constraints: budget ceiling, deadline, regulation, systems that cannot change. GOV.UK's advice to reframe a predetermined solution as a problem to be solved applies to most commercial projects too.

2. Research users and the current process

Interview the people who will use the product, not only the people who pay for it. Watch the current process if you can. Map who the users are, what they are trying to do and where they get stuck today. Gather evidence for the problem: numbers, complaints, observed workarounds.

3. Set goals and scope

Turn the problem into two or three goals, each with a metric, a current value, a target and a date. Then write down what is out of scope. An explicit "not in the first release" list prevents more arguments than any other single page.

4. Write the requirements

Describe what the product must do in short, testable statements. Give each a type (functional, non-functional or constraint), a priority (MoSCoW: Must, Should, Could, Won't), acceptance criteria for the Musts, and a link to the goal it supports. Do not forget non-functional needs: performance, security, availability, accessibility, data residency.

5. Explore the technical options

Check every integration: who owns it, whether its API exists, whether it is documented and what it can actually do. Draw a context diagram and a component diagram. Record each significant choice as a short decision record: the question, the options compared, the choice and its consequences. Spike anything that the estimate depends on and nobody has tried.

6. Sketch the key screens

Wireframe the three to five screens users will meet most. They exist to settle disagreements and expose missing requirements, not to finalize the visual design. Check them with a few real users if you can.

7. Plan, estimate and list the risks

Split the work into milestones that each deliver something usable. Estimate each as a low-high range in person-weeks and write down the assumptions the range relies on. Keep a single log of risks, blockers and open questions, each with an owner and a next step.

8. Decide and sign off

Write the executive summary last and present it to the decision maker. The meeting should end with one of three outcomes: build the agreed first release, change the scope or approach, or stop. Agree the first-release scope in writing.

Who takes part and what each person owes

A discovery team is small. In an NN/g survey of UX teams, a discovery had about four people working on it full time on average, most often a designer, a researcher and a product or project manager (NN/g). For software projects, the roles below are typical; one person often covers two of them.

Role	Side	What they owe the discovery
Sponsor / decision maker	Client	Goals, budget range, constraints, decisions on time, final sign-off
Product owner or client PM	Client	Day-to-day answers, access to people, data and documents, priorities
Users and subject-matter experts	Client	Interviews, walkthroughs of the current process, review of journeys and screens
Client IT / security	Client	System access, API documentation, security and compliance rules
Business analyst	Delivery team	Interviews, requirements, traceability to goals, the open-questions log
UX / product designer	Delivery team	Journeys, flows, wireframes, quick checks with users
Solution architect / tech lead	Delivery team	Integration checks, architecture, decision records, feasibility, estimates
Delivery or project manager	Delivery team	Plan and timebox, risk log, roadmap, the final readout
QA engineer (optional)	Delivery team	Testable acceptance criteria, test strategy for risky areas

The client side is where discoveries most often stall. If the sponsor cannot give a few hours a week and the users cannot be reached, extend the timeline or shrink the scope, but do not let the delivery team guess.

Deliverables: what you should hold at the end

A finished discovery leaves ten documents (or ten sections of one document), plus a risk log. They are the same ten sections as our discovery phase template.

Deliverable	What it contains	Done when
Stakeholders	Name, role, what they need, influence, open disagreements	You know who signs off and who can say no
Background	Business, current process and tools, past attempts, hard constraints	A new team member could start with it on day one
Executive summary	Problem, proposed solution, outcome, scope, timeline and cost range, the decision needed	The sponsor can read it in two minutes and decide
Problem statement	Who is affected, what goes wrong, how often, what it costs, the evidence	It names no solution and everyone agrees with it
Goals and success metrics	Two or three goals, each metric with today's value, target and date, KPIs to watch	Every goal can be judged later
User experience	Users and actors, journeys step by step, key flows as diagrams	The main journey of each user is mapped
Requirements	Testable items with type, MoSCoW priority, acceptance criteria, linked goal, owner	Every Must has acceptance criteria and traces to a goal
Architecture	Context and component diagrams, integrations, decision records	Every integration is checked and every big choice recorded
UI screens	Wireframes of the main screens, which requirements each covers	Stakeholders agree on what users will see
Roadmap and estimates	Milestones, dates, low-high person-week ranges, dependencies, assumptions	Each estimate states what it assumes
Risks, blockers and open questions	Each item with likelihood, impact, owner and next step	Nothing known is left unowned

To see what this looks like when it is filled in, the example discovery report shows all of these sections for Fieldwise, an invented field-service app for an invented heating company: five stakeholders, three goals with metrics, twelve requirements, three architecture decisions, four wireframes, four milestones with ranged estimates and seven risks and open questions. The names and figures are made up; the structure is the point.

Week-by-week plans for a 2-, 4- and 6-week discovery

These plans assume a core team of two to four people and a client who can give interviews within the first week. Treat them as starting points, not fixed recipes.

Two-week discovery

For a small MVP or a single workflow, with one or two integrations and a team that knows the domain.

When	Focus	Output
Days 1-2	Kickoff, existing material, stakeholder interviews	Stakeholders, background, draft problem statement
Days 3-5	User interviews, current process, goals	Journeys, goals with metrics, in/out scope
Days 6-8	Requirements, integration check, key screens	Prioritized requirements, context diagram, wireframes
Days 9-10	Estimate, risks, readout	Roadmap with ranges, risk log, executive summary, decision

Four-week discovery

For a typical new product or a significant rebuild: several user types, a few integrations, some unknowns.

Week	Focus	Output
Week 1	Kickoff, stakeholder interviews, existing material, constraints	Stakeholders, background, problem statement, research plan
Week 2	User research, current-process mapping, goals	Users and journeys, goals and metrics, scope list
Week 3	Requirements, architecture options, integration checks, first wireframes	Requirements with acceptance criteria, diagrams, decision records
Week 4	Wireframe review, estimates, risks, readout	Roadmap with ranges and assumptions, risk log, executive summary, sign-off

Six-week discovery

For complex or regulated work: several departments, legacy systems, data migration or compliance review.

Week	Focus	Output
Week 1	Kickoff, stakeholder map, existing systems and documents	Stakeholders, background, constraints, research plan
Week 2	User and stakeholder research across groups	Interview findings, users and actors, current journeys
Week 3	Problem, goals and scope; compliance and data review	Agreed problem statement, goals and metrics, data and compliance notes
Week 4	Requirements; architecture options; technical spikes on the riskiest integrations	Requirements draft, diagrams, spike results
Week 5	Wireframes and user checks; decision records; requirement review with the client	Wireframes, decision records, reviewed requirements
Week 6	Estimates, roadmap, risk review, readout	Milestones with ranges, assumptions, risk log, executive summary, decision

How long a discovery phase takes

There is no standard length. GOV.UK says there is no set time period and that around four to eight weeks is typical for public services, with a well-understood problem needing less. For commercial software projects, these ranges are a reasonable rule of thumb, not a measured average:

One to two weeks: a small MVP, one main user type, few integrations, a client who answers fast.
Three to six weeks: a typical product with several user types, a few integrations and some open technical questions.
Six to twelve weeks: regulated domains, many stakeholders, legacy replacement or data migration.

What actually sets the length: how many distinct user groups you must hear from, how many integrations you must verify, how quickly the client can make decisions, and whether a compliance review is involved. Calendar time is usually lost waiting for interviews and answers, not doing analysis. Time-box the phase anyway; an open-ended discovery tends to drift into design or build.

What a discovery phase costs

The honest way to price a discovery is in person-weeks:

cost = people on the team x weeks x their blended weekly rate

Discovery	Typical team (rule of thumb)	Effort
Two weeks	2 people (BA or PM, plus an architect part-time)	about 3-4 person-weeks
Four weeks	3 people (BA, designer, architect)	about 8-12 person-weeks
Six weeks	3-4 people, plus specialists for security or data	about 15-24 person-weeks

Multiply the effort by the rates you or your vendor charge. For example, at an illustrative blended rate of $4,000 per person-week (use your own figure), a four-week discovery of about 10 person-weeks costs about $40,000; at $1,500 per person-week, the same work costs $15,000. That spread is why quoted prices differ so much between agencies and countries.

Another common rule of thumb, mostly from agency guides, puts discovery at roughly 5-15% of the total build budget. Treat that as a sanity check rather than a fact: on a large project the share falls, and on a small, risky one it can be higher.

What pushes cost up: more user groups to research, integrations with poor documentation, regulated data, many decision makers, and requests for high-fidelity design inside discovery. What brings it down without skipping the work: sending existing material before kickoff, booking interviews in advance, one decision maker with real authority, and reusing a standard structure such as the discovery phase checklist instead of inventing one.

Discovery in agile and waterfall projects

In a waterfall project, discovery is a gate. Its output is a complete specification, a fixed scope and often a fixed price, and changes after it go through change control. The risk is spending weeks specifying details that will change anyway.

In an agile project, discovery sets direction rather than every detail. It produces the goals, the first-release scope, a prioritized backlog with the Musts detailed and the rest rough, an architecture that will not need to be thrown away, and a ranged estimate. Detailed discovery then continues in each sprint for the next items. The risk here is the opposite one: calling the first sprint "discovery" and never writing down goals, scope or risks at all.

Most teams land in between: a time-boxed upfront discovery that is thorough on goals, scope, integrations and risks, and deliberately light on anything the team will learn faster by building.

Red flags in a discovery proposal

Whether you are buying a discovery or writing one, check the proposal for these:

No list of deliverables. "Workshops and alignment" without named documents means you cannot tell when it is finished.
A fixed build price before discovery starts. If the vendor already knows the price, the discovery is either unnecessary or a formality.
No time with real users. Only the sponsor is interviewed.
No technical person. Nobody checks integrations, so the estimate is a guess.
Single-number estimates. Any estimate made before the build should be a range with its assumptions written down.
The deliverables are not yours. You should own the documents and be free to take them to another team.
No end date and no decision meeting. Time and materials with no time-box tends to grow.
Heavy visual design inside discovery. Polished screens look like progress but do not answer the risky questions.
The technology is chosen before the problem is understood. A recommended stack in the proposal itself is a warning sign.

Common mistakes

Starting from the solution. "We need an app" is not a problem statement. Reframe it before researching.
Talking only to the buyer. The people who pay for software are rarely the people who use it every day.
Writing a document nobody reads. Ten clear sections beat a long specification. The executive summary must stand on its own.
Skipping non-functional requirements. Performance, security, offline use and data residency change architecture and cost more than most features.
Estimating without assumptions. An estimate without its assumptions cannot be checked or defended later.
Leaving open questions unowned. Each needs a name and a date, or it will still be open at the start of the build.
Letting the documents drift apart. When a goal or requirement changes late, the architecture, screens and estimate that depend on it must change too.
Not involving the people who will build it. Developers who were absent from discovery will rediscover it, at build rates.

When a discovery phase is not worth it

Skip a formal discovery, or shrink it to a day or two, when:

the change is small and well understood, and a few tickets describe it fully;
you are building a throwaway prototype to test an idea, so the prototype is the discovery;
the same team has built the same kind of thing for the same client and little has changed;
the scope is fixed by someone else (a regulator or a contract) and the only open question is effort.

A useful test: if the discovery would cost more than the mistake it could prevent, keep it light. Even then, write down the problem, the goals, the Musts, the integrations and the top risks. That takes hours, not weeks, and it is the part that saves projects.

FAQ

How long does a discovery phase take?

Usually two to eight weeks. As a rule of thumb, one to two weeks for a small MVP, three to six for a typical product, and six to twelve for regulated or legacy-heavy work. The number of user groups, integrations and decision makers matters more than the size of the idea.

How much does a discovery phase cost?

Work it out as people x weeks x rate. A two-week discovery is roughly 3-4 person-weeks of effort, a four-week one roughly 8-12, a six-week one roughly 15-24. Your price is that effort times your rates. Agency guides often quote 5-15% of the build budget as a rough check.

Is the discovery phase paid, and who pays?

Usually yes, and the client pays, either as a fixed fee for a fixed time-box or as time and materials with a cap. Some vendors credit the fee against the build if you continue with them. A "free" discovery is either short or paid for later inside the build estimate. Whatever the model, make sure you own the deliverables.

Who takes part in a discovery phase?

On the client side: a sponsor who decides, a product owner, real users and someone from IT. On the delivery side: a business analyst, a designer, a solution architect or tech lead and a project manager. A core team of three to five people is common (a rule of thumb; an NN/g survey of UX teams found about four full-time people on average).

What is the difference between discovery, inception and scoping?

Discovery is the full upfront stage: problem, users, requirements, architecture, estimate and decision. Inception is usually a shorter, workshop-based kickoff for an agile team and overlaps with discovery. Scoping is one output of discovery: what is in, what is out and what it costs.

Can AI help with a discovery phase?

Yes, with the writing and checking, not with the decisions. AI is good at turning interview transcripts, decks and old specs into first drafts of requirements, journeys or a problem statement, and at spotting gaps and contradictions between sections. It cannot interview your users, judge which stakeholder is right or own a risk. Discovery Phase AI, for example, drafts the first stages (background, problem, stakeholders, goals, users and journeys, requirements) from documents, decks, transcripts and images you already have, helps you write and score the rest stage by stage, and you review every draft before anything is saved.

Disclosure and a sample

If you just want to see what a finished discovery looks like, here is a complete sample report for an invented field-service app. No signup needed.

The original of this post is on our blog. Questions or corrections are welcome in the comments.

This post was drafted with AI assistance and edited by a human before publishing.

How much does a software discovery phase cost? A person-weeks model

Oleksandr Tytarenko — Fri, 09 Oct 2026 08:41:55 +0000

A software discovery phase usually costs somewhere between a few thousand dollars and several tens of thousands, and large regulated projects go well beyond that. The honest answer is a calculation, not a number: people on the team x weeks x blended weekly rate.

This post shows what agencies publish, why the figures disagree, and how to build a range you can defend, whether you are buying a discovery or pricing one.

What agencies publish (and why it disagrees)

These are vendors' own figures for their own scope and rates, not market surveys:

Source	Price	Duration	What it covers
Wavect	3,500 EUR, fixed	2-3 weeks	Architecture, milestone plan, fixed-price build offer; fee deducted from the first build invoice if you continue
Acquaint Softtech	$2,500-$5,000 (MVP)	1 to 6 weeks	Ranges by project type, tied to build budgets of $15K to $500K+
Leanware	$5,000-$15,000, fixed	2-4 weeks	Its own "Sprint 0" price; the page says it is not an industry average
LowCode Agency	$5,000-$30,000 (mobile apps)	2-6 weeks	Mobile app discovery
Globaldev	$10,000-$40,000 (MVP)	Not fixed	Directional ranges by project size

Read side by side, an MVP discovery costs anything from $2,500 to $40,000. Nobody is necessarily wrong. They price different things:

Different work under the same name. Two weeks of workshops and a backlog is not the same as interviews, architecture, wireframes, a roadmap and a fixed-price build offer.
Different rates. Ten person-weeks cost very different amounts depending on where the team sits and how senior it is.
Different team sizes. One analyst for two weeks and a team of four for two weeks are both "a two-week discovery".
Different commercial intent. A low fixed fee, or one deducted from the build, is partly a sales tool.

The "discovery is 5-10% of the budget" rule of thumb is a sanity check, not a price.

What drives the cost

When two proposals differ a lot, compare them against this list first:

Scope of the question. "Can we replace this spreadsheet process?" is smaller than "Should we build a platform for three markets?"
Number of user groups. Each group needs its own interviews, journeys and requirements. Often the biggest single driver.
Integrations. Each system the product must talk to has to be checked. Legacy or poorly documented ones take far longer.
Compliance and data. Health, finance, personal data and data residency add reviews and sometimes a specialist.
Team composition. An analyst alone is cheaper than an analyst, designer and architect, but cannot check integrations or sketch screens.
Decision speed. Calendar time is usually lost waiting for interviews and answers.
Depth of design. Low-fidelity wireframes are enough; polish answers none of the risky questions.

A worked cost model

cost = people on the team x weeks x blended weekly rate

The rates below are illustrative assumptions chosen to show the spread, not survey data. Replace them with your own or your vendor's.

Size	Typical team	Person-weeks	$1,500/wk	$2,500/wk	$4,000/wk
2 weeks	2 people (BA/PM, architect part-time)	3-4	$4,500-$6,000	$7,500-$10,000	$12,000-$16,000
4 weeks	3 people (BA, designer, architect)	8-12	$12,000-$18,000	$20,000-$30,000	$32,000-$48,000
6 weeks	3-4 people plus security/data specialists	15-24	$22,500-$36,000	$37,500-$60,000	$60,000-$96,000

You can also run it backwards to read a quote. Divide the price by a plausible blended rate and you get the effort the vendor priced in. If a four-week discovery works out to two or three person-weeks, then the team is one person part-time, the scope is narrow, or the fee is partly recovered in the build. Know which one you are buying.

Two adjustments worth adding: client time (your sponsor and users spend hours in interviews; it is not on the invoice, but it is the most common cause of delay) and a 10-20% contingency if the scope is unclear going in.

Pricing models

Model	Good for	Watch out for
Fixed fee	Budget certainty, well-framed questions	Vendor prices in risk; anything outside the list is a change request
Time and materials with a cap	Exploratory work	Without a cap and an end date, it grows
Credited against the build	Buyers fairly sure they will build with this team	Check you still own the deliverables if you do not continue
"Free" discovery	Very early conversations	Cost is recovered in the build estimate

Whatever the model, the contract should say what you receive, when the phase ends, and that the documents are yours to take to another team.

Questions to ask before you sign

Which named documents will we receive, and what does "done" mean for each?
Who is on the team, for how many days each, and at what rate?
How many user interviews are included, and with which groups?
Which integrations will be checked, and by whom?
Is the final estimate a range with written assumptions, or a single number?
What happens if the phase runs over: change request, cap, or extra invoice?
Is the fee credited against the build, and do we own the deliverables if we go elsewhere?

Keeping the cost down without skipping the work

Savings come from removing waiting and rework, not from cutting stages:

Send everything you have before kickoff: decks, old specs, support tickets, interview notes.
Book user interviews before the phase starts.
Name one decision maker who can answer within a day or two.
Discover the first release in depth and leave later phases rough.
Keep design low-fidelity.

Where the person-weeks go (if you run discovery)

For the agency or in-house team, the work splits in two. Talking and deciding (kickoff, interviews, workshops, readout) can only be shortened by better preparation and faster client answers. Writing and assembling (reading the client's material, turning notes into a problem statement, journeys and requirements, keeping goals, requirements, estimates and risks consistent, formatting the final document) is mostly synthesis of text that already exists, and it is where rework piles up: one late change to a goal has to be carried through the architecture, screens, estimate and risk log by hand.

Check your own timesheets for how large that second share is. It is the part you can shorten without cutting the discovery itself.

Disclosure and a sample

I build Discovery Phase AI, a tool aimed at that second kind of work: it drafts the early stages from the decks, documents and call transcripts you already have, and exports one report. Your team still runs the interviews, reviews every draft and makes the decisions.

If you just want to see what a finished discovery looks like, here is a complete sample report for an invented field-service app. No signup needed.

The longer version of this post, with the full FAQ, is on our blog. Questions or corrections to the numbers are welcome in the comments.