Software Development Discovery Phase: Process, Costs, and Deliverables (2026)

1 hour ago

22 min read

Software discovery phase covering process, costs, and deliverables.

Imagine a founder who collects three quotes for the same client portal and receives $18,000, $64,000 and $140,000. None of the vendors is lying. Each priced a different set of unwritten assumptions about users, integrations, security and scope. The discovery phase exists to replace those assumptions with documented decisions before real money goes into code. This guide explains how software discovery works, what it costs, which deliverables you should receive and how to judge whether it is worth buying.

TL;DR

Definition: discovery is a time-boxed phase that turns a business idea into validated requirements, risks, a roadmap and an estimate, without building the product.
Process: eight adaptable stages, from stakeholder alignment to a go, change or no-go review.
Cost: there is no universal price. Effort scales with stakeholders, integrations, data sensitivity and research depth. The illustrative budgets below range from $2,550 to $33,000 and are not quotes.
Deliverables: problem statement, requirements, prioritized MVP scope, workflows, architecture options, risk log, roadmap and an estimate with stated assumptions.
Next decision: proceed, reduce scope, buy existing software, run a technical proof of concept, or stop.

Quick Answer

The software development discovery phase is a time-boxed, pre-build stage in which a team clarifies the business problem, users, requirements, technical constraints and risks. It produces prioritized scope, a roadmap and an estimate with stated assumptions. Costs vary with complexity, and the outcome should be a clear go, change or no-go decision.

What Is the Software Development Discovery Phase?

The software development discovery phase is a bounded period of structured investigation that happens before design and build commitments are made. Its purpose is to establish what should be built, for whom, under which constraints, at what level of risk and for roughly what investment. The output is evidence and decisions, not software.

Discovery usually covers four areas: the business problem and measurable objectives, the people and workflows involved, the functional and non-functional requirements, and the technical landscape, including integrations, data and security. Teams gather that evidence through interviews, workshops, workflow mapping, document review, low-fidelity prototypes and short technical spikes.

Project discovery versus continuous product discovery

Two meanings circulate. Product discovery is an ongoing habit of testing ideas with users, and it never really ends. Project discovery, the subject of this guide, is a bounded engagement that prepares one specific build decision. The two overlap, but a vendor selling the second should not be expected to deliver the first.

What discovery can and cannot do

Discovery reduces uncertainty; it does not remove it. It cannot guarantee a fixed final price, prove that users will adopt a product or replace testing during delivery. The UK Government Digital Service, which popularised the discovery phase for public services, says a team should not start building during discovery and that stopping at the end is not a failure when the research shows it is the best choice (How the discovery phase works, GOV.UK).

Why Discovery Matters and When to Run, Shorten or Skip It

Software projects tend to go wrong at the edges of what nobody wrote down. Typical gaps are an approval step only one manager knows about, a third-party API that rate-limits the data you need, or a security review that appears after the screens are built. Each gap is cheap to find on paper and expensive to find in code, which is the practical argument for discovery. It is a reasoned argument, not a guarantee: no source promises that discovery prevents failure or lowers every build bill.

Discovery also aligns people. When the sales lead, the operations manager and the finance owner each describe a different "client portal", a workshop that ends in written decisions is cheaper than months of rework. The software requirements checklist covers the questions to settle before you speak to developers.

Not every project needs a paid, multi-week engagement. The matrix below shows how the best route changes with uncertainty.

Situation	Suggested route	Reasoning
Small tool, one team, clear steps	Short scoping call and written brief	Little uncertainty, so a long study would cost more than it saves
New process nobody has mapped	Full discovery	Requirements are unknown and users must be observed
Several systems must connect	Discovery with an integration spike	API access and data quality decide feasibility
Regulated or sensitive data	Discovery with security and privacy review	Controls shape architecture and cost
Ready-made software covers most needs	Evaluate existing products first	Buying or configuring may beat building
Legacy system replacement	Discovery plus data inventory	Hidden rules and migration effort dominate risk

Honest providers sometimes recommend the lighter route, or no build at all. The Articsledge custom web application development service takes the same position: it considers whether building, integrating or improving existing tools offers the best value, and notes that a separate paid discovery phase may apply depending on project complexity. Decision guides such as build vs buy software and custom software vs SaaS help frame that choice before any vendor conversation.

Discovery vs. Scoping, Inception, Workshops, Prototypes, Proofs of Concept and MVPs

These terms blur together in proposals, so check what is actually being sold. PMI's Disciplined Agile guidance describes an inception phase, also called project initiation, start-up or sprint zero, as doing just enough work to point a team in the right direction (The Inception Phase, PMI). That is narrower than most commercial discovery, which usually adds user research, feasibility work and estimation.

Activity	Main purpose	Main output	What it does not establish
Discovery	Decide whether and how to build	Requirements, scope, risks, roadmap, estimate	Final quality or user adoption
Scoping call	Agree rough boundaries	Short brief and ballpark range	Detailed feasibility
Inception or sprint zero	Start a delivery team quickly	Vision, initial backlog, team agreements	Deep user research
Workshop	Align stakeholders in a session	Decisions, priorities, notes	Evidence from real users or systems
Prototype	Test an interface idea	Clickable screens	Technical or data feasibility
Proof of concept	Test one technical risk	Working evidence on a narrow question	A production-ready design
MVP	Learn from real use	A limited live product	The full requirements

A workshop is a tool inside discovery, not a substitute for it. A prototype shows what a screen might look like; it says little about whether an API will return the records that screen needs. For the budget side of the last row, see MVP development cost.

The Software Discovery Process, Step by Step

The eight stages below are adaptable. Small projects compress them into days, and complex ones repeat several. Each entry names the activity, the people involved, the decision it supports and a common failure mode.

1. Kickoff and stakeholder alignment

Agree the goal of discovery, the decision it must support, the stakeholder map and the ground rules for access and availability. Participants are the sponsor, product owner, delivery lead and key department heads. The decision is who may approve scope and budget. The usual failure is treating discovery as a formality for a solution already chosen. GDS advises reframing a requested solution as a problem to solve, so "build an interactive map" becomes "how can people find their nearest office?"

2. Business problem and success measures

Write the problem statement, estimate what the problem costs today in hours, errors, delays or lost deals, and define measurable success criteria. Useful evidence includes time logs, support tickets and error counts. A sample criterion: cut client onboarding from 12 working days to 6. The usual failure is an objective such as "modernize" that nobody can verify.

3. Users, research and workflow mapping

Interview and observe the people who will use, approve and support the software, then map the current workflow and a proposed future one. GDS guidance on user research in discovery recommends researching with a broad range of users, including disabled people and people with low digital skills, and also speaking to the staff who support others. Sample interview questions: What triggers this task? What do you do when information is missing? Who must approve it? What do you dislike about today's tools? The usual failure is interviewing only managers.

4. Requirements elicitation and validation

Convert findings into functional requirements (what the system does), non-functional requirements (performance, availability, accessibility, security, audit, retention) and testable acceptance criteria. ISO/IEC/IEEE 29148 describes requirements engineering processes and information items. The 2018 edition is the published version, and ISO lists a revision in development (ISO/IEC/IEEE 29148:2018). Use it as a quality lens, meaning clear, verifiable and traceable, not as a paperwork quota. The usual failure is a feature list with no acceptance criteria.

5. MVP scope and priorities

Rank requirements with a method such as MoSCoW (must, should, could, won't), define the smallest release that delivers measurable value and record what is deliberately excluded. The decision is what ships first and what waits. The usual failure is an MVP that contains every stakeholder's wish.

6. Technology, integration, security and data feasibility

Identify the systems to connect, confirm API access, rate limits and permissions, inventory the data and its quality, outline architecture options and note security, privacy and hosting constraints. An API that exists on paper may not expose the records you need, and middleware or an iPaaS platform may be cheaper than custom connectors. Participants include the architect, engineers, system owners and a security or compliance contact. The usual failure is assuming integration will work because a brochure says so.

7. UX flows, wireframes and technical spikes

Sketch key flows and wireframes, test them with representative users and run short, time-boxed spikes on the riskiest technical questions. Prototype fidelity should match the decision at hand: low fidelity to test workflow, higher fidelity only when stakeholder buy-in or usability testing needs it. The usual failure is polishing screens while the integration question stays unanswered.

8. Risk, estimate, roadmap and go/no-go review

Consolidate the risk and assumption logs, produce an estimate with a confidence level, outline milestones and hold a decision meeting. Possible outcomes are to proceed, proceed with reduced scope, run a proof of concept, buy or configure existing software, or stop. The usual failure is a review that can only ever say yes.

Roles and Decision Rights

Discovery fails quietly when nobody can say yes. Name one accountable approver for scope and one for budget; in a small company they may be the same person.

Role	Main contribution	Decision rights	Often combined with
Business sponsor	Funds the work and defines value	Budget and go/no-go	Founder or executive
Product owner	Owns priorities and acceptance	Scope and priority calls	Operations lead
Business analyst	Runs interviews, writes requirements	Recommends scope	Product owner
Delivery lead	Tracks schedule, risks and process	Process and timeline	Business analyst
UX designer	Flows, wireframes, usability tests	Interaction design	Front-end engineer
Architect or tech lead	Feasibility and architecture options	Technical approach	Senior engineer
Security and QA reviewer	Non-functional and test criteria	Risk-acceptance advice	Architect
System and data owners	Access and data facts	Permissions	IT manager
Representative users	Evidence of real work	Validate workflows	None

On a small project one person may cover several rows. What should not be merged is the vendor's recommendation and the client's sign-off: the client keeps the final decision.

Typical Timeline and Completion Criteria

The GDS service manual says there is no set time for a discovery, but around four to eight weeks is typical in its public-service context. That is not a commercial benchmark. Duration is driven by stakeholder availability, access to systems and users, research depth and how much is already known.

As an assumption-based illustration, a small internal workflow might take one to two calendar weeks, a medium B2B portal four to six weeks and an integration-heavy platform eight to twelve weeks. Calendar time differs from billable effort: a five-week discovery may include only 110 working hours, because much of the elapsed time is spent waiting for interviews, access and feedback. For delivery schedules that follow discovery, see the web app development timeline.

Define completion in advance. A defensible exit checklist:

The problem statement and success measures are approved in writing.
Priority users and workflows have been observed or interviewed.
Requirements are prioritized, with MVP scope and exclusions listed.
Integration and data feasibility are tested, or clearly marked as unproven.
Risks, assumptions and dependencies have named owners.
The estimate states its assumptions, exclusions and confidence level.
The sponsor has recorded a go, change or no-go decision.

Discovery Costs and Pricing Models

No credible universal price exists for discovery, because the work is mostly skilled people's time and scope varies. Clutch's software development pricing guide, updated September 21, 2026, reports hourly rate bands for development providers in general: most providers it lists charge roughly $25 to $49 per hour, with higher bands in markets such as the United States, Canada and Australia (Software Development Company Pricing Guide, Clutch). That is general development data, not discovery-only pricing, and it should not be treated as a discovery quote.

Common pricing models for discovery:

Fixed fee for a defined set of deliverables: predictable, but scope changes need change orders.
Capped time and materials: you pay for hours worked up to a ceiling, which keeps flexibility inside a budget limit.
Time and materials: flexible, but it needs regular reporting and budget checkpoints.
Workshop-only package: a short alignment engagement that is useful but not equal to full discovery.
Included assessment: light scoping offered before a build proposal, without a separate charge.
Separately paid discovery: a stand-alone engagement whose deliverables you own under the agreed terms.

"Free discovery" deserves scrutiny. If it is a sales conversation that ends in a proposal, it is an assessment, and that is fine. If it produces detailed documents, check who owns them and whether another vendor may use them. The Articsledge service page does not publish a fixed discovery price; it states that scope and commercial terms are agreed per project. For the wider build budget, see custom software development cost, and for contract structures, fixed-price vs time-and-materials software development.

Cost Drivers and a Transparent Budget Model

Discovery effort rises with the number of decisions to untangle. The main drivers are:

Stakeholder and user groups to interview or observe
Number of applications, integrations and legacy systems
Regulated or sensitive data, which adds privacy and security analysis
Depth of user research and usability testing
Prototype fidelity and review rounds
Documentation depth, workshops and travel

The budget formula is simple: discovery cost = estimated billable role-hours x applicable hourly rate(s) + agreed expenses. Keep contingency, taxes, third-party fees and travel visible as separate lines so comparisons stay fair, and keep implementation spend out of the discovery figure. Ask each provider for hours by role, because a quote without hours cannot be compared or challenged. Post-launch costs are a separate line again; software maintenance cost explains what to plan for.

Three Worked Discovery Budgets

The figures below are hypothetical illustrative scenarios built on assumed rates. They are not market averages, Articsledge quotations or guarantees. The blended rates represent mixed analyst, design and architecture time and should be replaced with a real provider's rate card.

Scenario 1: small internal workflow tool

Assumptions: one department, about 15 users, a single approval workflow, no external integrations, two calendar weeks. Hours: business analyst 14, UX designer 6, architect 4, delivery lead 4, QA and security reviewer 2, total 30. Blended rate: $85. Calculation: 30 x $85 = $2,550, plus $0 expenses, equals $2,550. Exclusions: build, hosting, legal review. Main uncertainty: undocumented exceptions in the approval rules.

Scenario 2: medium B2B client portal

Assumptions: three user roles, one CRM integration, document exchange, an approval flow and a basic security review over five calendar weeks. Hours: analyst 36, designer 24, architect 16, delivery lead 14, QA and security 8, engineer spike 12, total 110. Blended rate: $95. Calculation: 110 x $95 = $10,450, plus $350 expenses for research tools and participant incentives, equals $10,800. Main uncertainty: the CRM's API limits.

Scenario 3: integration-heavy business platform

Assumptions: five or more user roles, three to four systems to connect, data migration, sensitive data and formal security requirements over ten calendar weeks. Hours: analyst 90, designer 50, architect 56, delivery lead 36, QA and security 28, engineer spikes 40, total 300. Blended rate: $105. Calculation: 300 x $105 = $31,500, plus $1,500 expenses, equals $33,000. Main uncertainty: legacy data quality and vendor access.

Scenario	Hours	Blended rate	Labour	Expenses	Total	Total with 15% labour reserve
1. Small workflow	30	$85	$2,550	$0	$2,550	$2,932.50
2. B2B portal	110	$95	$10,450	$350	$10,800	$12,367.50
3. Integration-heavy	300	$105	$31,500	$1,500	$33,000	$37,725.00

The reserve column adds an illustrative 15 percent of labour ($382.50, $1,567.50 and $4,725.00) and is shown separately because a reserve is a risk decision, not a work estimate. Change any assumption and the figure moves: an extra interview round, a second integration or a stricter accessibility target each adds hours. For budgets that extend into the build, web app development cost gives a wider view.

The Deliverables Checklist: What You Should Receive

Deliverables are the adaptable contents of a discovery package, not twenty mandatory documents. Several can share one file. What matters is that each answers a decision someone must make. The table lists the core set; add prototypes, a data migration inventory or a privacy assessment where the project calls for them.

Deliverable	Why it matters	What good looks like	Reviewer or owner
Problem statement and objectives	Anchors every later decision	One page, measurable targets, agreed exclusions	Sponsor
Stakeholder and user map	Shows who is affected and who decides	Roles, needs, influence and access	Product owner
Current and future workflows	Exposes manual steps and exceptions	Main path and top exceptions, validated by users	Operations lead
Functional requirements	Defines behaviour	Each item testable and traced to a need	Product owner, analyst
Non-functional requirements	Controls security, speed, access	Measurable targets such as roles, uptime, WCAG level	Architect, security reviewer
Prioritized backlog and MVP scope	Prevents scope sprawl	Ranked items, first release, explicit exclusions	Sponsor
User stories and acceptance criteria	Makes "done" checkable	Given/When/Then statements	QA, product owner
Architecture and integration assessment	Shows feasibility	Options, trade-offs, proven or unproven API access	Architect, system owners
Risk, assumption and dependency log	Keeps uncertainty visible	Owner, impact and next action for each item	Delivery lead, sponsor
Roadmap and estimate	Supports budgeting	Milestones, range, assumptions, confidence	Sponsor, finance
Recommendation	Closes the phase	Proceed, change, buy or stop, with reasons	Sponsor

Reference verifiable standards rather than vague promises. ISO/IEC/IEEE 29148 specifies information items and expected content for requirements work, which gives buyers a vocabulary for completeness without dictating a template. For security, OWASP positions its Application Security Verification Standard (version 5.0.0, published 30 May 2025) as a basis for specifying security verification requirements in contracts. For accessibility, W3C advises using WCAG 2.2 for new work, so the target conformance level belongs in the requirements.

How to Evaluate, Accept and Own Deliverables

Treat acceptance as a review of evidence, not a signature on a PDF. Test each deliverable against these questions:

Testable: could someone write a test from this requirement?
Traceable: can each requirement be traced to a user need and a business objective?
Bounded: is the MVP separated from later ideas, with exclusions stated?
Honest about uncertainty: are unproven assumptions flagged, with owners?
Editable and versioned: do you receive source files, not only exports?
Portable: could another vendor price the work without a verbal briefing?

Ownership should be written down. Source files, designs, research notes and any prototypes created during discovery may be governed by the contract, third-party licences and local law, so agree who owns what, how confidentiality applies and whether you may share the package with other suppliers. The Articsledge service page says source code rights, intellectual property and handover obligations belong in the project agreement. This is general information, not legal advice; have counsel review the contract. When a build proposal follows, the guide to evaluating a software development proposal helps you test it.

Sign-off checklist:

Every deliverable named in the contract has been received and opened.
Open questions and assumptions have owners and dates.
Source files, research data and access details have been handed over.
A second vendor could price the work from the package.
The sponsor has recorded the decision in writing.

Worked Example: Discovery for a B2B Client Portal

This is a hypothetical scenario, not an Articsledge client or case study. A fictional 45-person consulting firm runs client onboarding through email threads and spreadsheets. Document approvals happen by reply, project status is updated by hand every Friday and partners cannot tell which clients are waiting on whom.

Problem, users and workflow

Stakeholders: the managing partner (sponsor), operations manager (product owner), two project managers, finance and an IT contractor. User types: client contact, client approver, consultant and administrator. In this fictional baseline onboarding takes 12 working days; the target is 6. The workflow runs from invitation to contract documents, intake form, approval, kickoff and ongoing status updates.

Requested features and the MVP split

The first wish list is long, so discovery sorts it:

MVP, must: client sign-in with role-based access
MVP, must: document upload with versions and approval status
MVP, must: an onboarding checklist visible to client and consultant
MVP, should: a weekly status view fed from the CRM project record
Later: invoicing and payments, a chat module, a mobile app and advanced analytics

The CRM exposes project records through an API with daily request limits, so a spike tests whether status data can be read reliably. Because clients must never see each other's files, tenant isolation, audit logging and retention rules become non-functional requirements. For the surrounding choice, see client portal vs shared drive and self-service portal software. Two sample acceptance criteria:

Given a client approver is signed in, when they open another client's document link, then access is denied and the attempt is logged.
Given a consultant uploads version 2 of a contract, when the client approves it, then the status changes to Approved and version 1 stays in the history.

Activities, deliverables and decision

Over five calendar weeks, matching illustrative Scenario 2 at about $10,800, the team runs nine stakeholder interviews and six client interviews, maps two workflows, tests clickable wireframes with five users and completes the CRM spike. The package contains a problem statement, role matrix, workflow maps, requirement set, MVP backlog with exclusions, architecture options, risk log, estimate range and a recommendation. The decision: proceed with a reduced MVP once the CRM limits are confirmed, and keep payments out of version one. In a different run, discovery might find that a shared drive plus an approval tool covers most of the need and recommend no custom build. Once scope is clear, client portal development cost shows how budgets develop.

Technical, Security, Data and Operational Risks

Discovery surfaces risks; it does not verify security. A risk workshop is not a penetration test, a compliance certification or a build. It does help you write the right requirements early, using public references.

Authentication and authorization: how users sign in, which roles exist and how tenants are isolated. The OWASP Top 10:2025 and ASVS 5.0.0 give shared vocabulary for web application risks and verification.
Secure development practice: NIST SP 800-218, the Secure Software Development Framework version 1.1 (February 2022), gives purchasers and suppliers a common vocabulary for secure development practices (NIST SP 800-218).
Third-party APIs and vendors: quotas, deprecations, approvals and contract limits.
Data quality and migration: duplicates, missing fields and retention. A primer on the database management system can help non-specialists follow these conversations.
Privacy and compliance: what personal data is stored, where and for how long. See cloud compliance for the regulatory landscape.
Availability and operations: backups, monitoring, hosting and incident contacts. Cloud architecture, cloud security and DevOps explain common patterns.
Accessibility and performance: a target WCAG 2.2 level and expected load.
Auditability: who changed what, and when, which audit trail software concepts illustrate.

For each risk, record impact, likelihood, an owner and the step that would reduce it, such as a spike, a vendor question or a new requirement.

From Discovery to Proposal and Development

Discovery should make the next proposal more specific. Early ballpark ranges become more reliable as unknowns close, but no estimate is exact. Ask for a range with a confidence level, for example "most likely 520 to 640 hours, with two named risks that could push it higher".

Preliminary estimate: a broad range given before discovery ends.
Scoped estimate: tied to the MVP backlog and stated assumptions.
Fixed price: works best when scope and acceptance criteria are stable.
Capped time and materials: suits scope that will keep evolving.

A statement of work should list deliverables, milestones, acceptance rules, assumptions, exclusions and a change-control process. Expect discovery to continue during delivery: new facts will appear, and a healthy change process absorbs them. If the answer after discovery is to buy rather than build, that is a successful result, and SaaS options are covered in the SaaS overview. Teams weighing external delivery can read about software development outsourcing.

How to Compare Discovery Providers

Ask every provider the same questions and compare the written answers. Strong answers are specific, name deliverables and admit limits.

What exactly is included, and which deliverables are contractual?
Who works on it, and how many hours does each role contribute?
How will you validate requirements with real users?
How are integrations tested rather than assumed?
How are assumptions, risks and open questions recorded?
How is the estimate built, and what confidence level is stated?
Who owns the outputs, and can another vendor use them?
In which editable formats will files be delivered?
How many revision rounds are included, and how are extra changes priced?
What happens if discovery shows custom development is unsuitable?
How are security, privacy and accessibility handled at this stage?
What does handover include?
Can you show a sample deliverable with client details removed?

A weighted scorecard keeps the comparison honest. Illustrative weights: transferable deliverables 20 percent, evidence of user and integration validation 20, estimate transparency 20, relevant experience 15, communication 15 and price 10. Adjust them to your priorities. Price is deliberately not dominant because the cheapest discovery often skips the interviews that make it useful. Related reading: questions to ask a software development agency, how to choose a custom software development company and freelancer vs software development agency.

Mistakes and Red Flags

Red flag	Why it hurts	Remedy
Solution-first scoping	Locks in a design before the problem is understood	Reframe as a problem with measurable outcomes
No real users involved	Requirements reflect opinions	Interview and observe users
Vague "documentation package"	Completeness cannot be verified	Name each deliverable in the contract
Guessing API access	Late surprises	Test with a spike, or mark as unproven
Ignoring non-functional needs	Security and accessibility get retrofitted	Require measurable targets
Quote certainty with no assumptions	Hides risk	Demand ranges, assumptions and exclusions
No decision at the end	Discovery becomes a loop	Hold a go/no-go review
Forced handoff to one vendor	Creates lock-in	Agree ownership and portability up front

Excess documentation is the opposite failure: hundreds of pages nobody reads. Aim for the smallest package that supports the decision.

A Discovery Preparation Checklist and What Comes Next

A one-page brief shortens discovery and sharpens quotes. Copy this list and fill it in:

Problem: what hurts today and what it costs
Users: who uses, approves and supports the software
Workflows: the three most important
Current systems and data: tools, owners and access
Constraints: deadlines, regulation, hosting and a budget band
Decision-maker: who signs off
Success measure: one number that proves it worked

After discovery, review the evidence with the sponsor and choose: proceed, reduce scope, run a proof of concept, buy existing software or stop. Keep the package, because it stays useful to any later vendor. For readers considering a client portal, internal tool or workflow application, Articsledge's project assessment starts from the business problem, and the guides to internal tool development and custom business software show typical use cases.

FAQ

What is the discovery phase in software development?

It is a bounded phase before building in which a team clarifies the problem, users, requirements, technical constraints and risks, then produces scope, a roadmap and an estimate. The aim is a decision about whether and how to build.

Is discovery necessary for every software project?

No. Small, well-understood tools may need only a short scoping call and a written brief. Discovery pays off when requirements are uncertain, several systems must connect, sensitive data is involved or stakeholders disagree.

How much does software discovery cost?

There is no universal figure. Cost equals billable hours times rates plus expenses. The hypothetical examples in this guide range from $2,550 to $33,000, but they are illustrations, not quotes. Ask providers for hours by role.

How long does the discovery phase take?

Often a few weeks. GDS says four to eight weeks is typical for public services, while a small commercial tool may need days and a complex platform longer. Access to people and systems is usually the deciding factor.

What does a discovery workshop include?

Typically stakeholder alignment, problem framing, workflow mapping and prioritization in facilitated sessions. It produces decisions and notes. A workshop alone does not replace user research or technical feasibility checks.

What deliverables should I receive?

At minimum: a problem statement with measurable goals, user and workflow maps, prioritized requirements with MVP scope and exclusions, acceptance criteria, architecture and integration findings, a risk log, a roadmap, and an estimate with assumptions plus a recommendation.

Can discovery be free?

A free assessment can be reasonable as a sales step. Be careful when it produces detailed documents without clear ownership or portability. Paid discovery usually gives you deliverables you can take to other vendors, subject to the agreement.

Who owns discovery documents?

Ownership depends on the contract and applicable law. Agree in writing who owns documents, designs and research notes, how confidentiality works and whether you may share them. Have counsel review it; this is general information.

Can another agency use the deliverables?

Yes, if the contract allows it and the files are complete and editable. Ask for source files and a package another team could price without verbal explanation.

Is product discovery the same as project discovery?

No. Product discovery is a continuous practice of testing ideas with users. Project discovery is a bounded phase that prepares a build decision. They overlap but differ in duration, goals and outputs.

What is the difference between discovery and an MVP?

Discovery produces knowledge and a plan. An MVP is a limited working product released to learn from real use. Discovery helps define what the MVP should contain.

Do developers write code during discovery?

Only small, time-boxed spikes or prototypes that test risky questions, such as whether an API returns the needed data. Production code is not the goal, and GDS guidance says not to start building during discovery.

Can discovery show that I should not build?

Yes, and that is a valid result. Constraints, cost-benefit analysis or existing products may make building a poor choice. Stopping at the end of discovery can save time and money.

How accurate are estimates after discovery?

More reliable than a first guess, never exact. Good estimates state ranges, assumptions, exclusions and confidence levels, and are revisited as new facts appear during delivery.

What happens if requirements change?

Change is normal. Use a change-control process that records the request, its effect on scope, cost and schedule, and an approval decision before work proceeds.

How do I prepare for a discovery meeting?

Bring a one-page brief covering the problem, users, workflows, current systems, constraints, budget band, decision-maker and one success measure. Arrange access to people and systems in advance.

Key Takeaways

Discovery is a decision tool: it should end in proceed, change, buy or stop.
Match the effort to the uncertainty; small, clear tools may need only a brief scoping step.
Insist on named deliverables, with ownership and portability written into the contract.
Ask providers for hours by role and for estimates with assumptions and confidence levels.
Validate requirements and integrations with real users and real systems, not assumptions.
Treat the illustrative budgets here as formulas to adapt, never as market prices or quotes.
Write non-functional targets for security, privacy and accessibility from the start.

Actionable Next Steps

Write the one-page brief from the preparation checklist.
List your top three workflows and the people who perform them.
Identify every system the software must connect to and who owns access.
Set a budget band and name the person who approves scope.
Decide whether existing software could meet most of the need.
Ask two or three providers the comparison questions above and compare hours, deliverables and ownership terms.
If a custom client portal, internal tool, dashboard or workflow application looks right, Request a Project Assessment from Articsledge and describe the problem, users and budget.

Glossary

Acceptance criteria: Testable conditions a feature must meet to be accepted.

API: An interface that lets one system request data or actions from another.

Assumption log: A record of unproven beliefs the plan depends on.

Blended rate: An average hourly rate across the roles on a team.

Discovery phase: A bounded pre-build investigation of the problem, requirements, risks and feasibility.

Go/no-go decision: A formal choice to proceed, change course or stop.

MoSCoW: A prioritization method: must, should, could, won't.

MVP: A minimum viable product, the smallest release that delivers measurable value.

Non-functional requirement: A quality target such as security, performance or accessibility.

Proof of concept: A narrow test of whether one technical idea works.

Risk register: A log of risks with impact, owner and mitigation.

Spike: A time-boxed technical investigation of one question.

Statement of work: A contract document defining deliverables, schedule and terms.

Time and materials: A pricing model that bills for actual effort, often with a cap.

Sources & References

UK Government Digital Service. How the discovery phase works. GOV.UK Service Manual. Published 4 August 2016; last updated 21 June 2021. https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works

UK Government Digital Service. User research in discovery. GOV.UK Service Manual. Published 18 November 2016. https://www.gov.uk/service-manual/user-research/user-research-in-discovery

Project Management Institute. The Inception Phase. Disciplined Agile. n.d. https://www.pmi.org/disciplined-agile/inception-goals

ISO/IEC/IEEE. ISO/IEC/IEEE 29148:2018, Systems and software engineering, Life cycle processes, Requirements engineering. Published November 2018. https://www.iso.org/standard/72089.html

Souppaya, M., Scarfone, K., Dodson, D. NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1. National Institute of Standards and Technology. February 2022. https://csrc.nist.gov/pubs/sp/800/218/final

OWASP. Application Security Verification Standard 5.0.0. Published 30 May 2025. https://asvs.owasp.org/

OWASP. OWASP Top 10:2025. n.d. https://top10.owasp.org/2025/en/

W3C. Web Content Accessibility Guidelines (WCAG) 2.2. W3C Recommendation, 12 December 2024. https://www.w3.org/TR/WCAG22/

Clutch. Software Development Company Pricing Guide. Updated 21 September 2026. https://clutch.co/developers/pricing