The short answer
A software discovery phase has no reliable universal price or percentage of build cost. Compare proposals by the uncertainty they investigate, the people and systems involved, the evidence you will receive and the decision that evidence supports. ApexStack’s Product Blueprint starts from US$1,000 for one bounded product or technical question; it is a planning and de-risking engagement, not an application build.
How much does a software discovery phase cost?
The honest answer is that discovery pricing follows the evidence gap, not a fixed percentage of the future build. Reviewing one core workflow with known users and accessible systems is a different engagement from investigating several departments, undocumented legacy software, regulated data and disputed requirements. A useful proposal names that boundary before it gives a price.
ApexStack’s Product Blueprint starts from US$1,000 for one bounded product or technical question. The agreed output may be a workflow definition, feasibility review, prototype assessment or technical risk decision. It does not include a complete production application. If the question is broader, the written scope and quote must broaden with it.
What should the discovery price be based on?
Ask the supplier to show which unknowns create the work. Team size and workshop count are inputs, but they do not tell you whether the engagement will produce a decision you can use.
| Unknown to investigate | Evidence required | Why it changes the scope |
|---|---|---|
| User problem and current workflow | Research with the people doing the work, plus existing support or operational evidence | More user groups and channels create more journeys to understand |
| Business rules and exceptions | A map of the normal path, failure states, approvals and manual workarounds | Hidden exceptions can change the product boundary |
| Existing systems and data | Access to interfaces, exports, ownership records and integration documentation | Undocumented dependencies require technical investigation |
| Security, privacy and compliance | Named obligations, data categories and responsible reviewers | Specialist review may be needed before a solution is feasible |
| Solution uncertainty | Assumptions, technical options and the smallest test that could reject each option | A known implementation needs less exploration than an untested mechanism |
| Decision and stakeholder access | A decision owner and access to the people who hold essential context | Unresolved ownership can leave the same questions open at the end |
What should you receive from paid discovery?
The deliverables should preserve the evidence and the decisions, not merely record that meetings happened. GOV.UK’s Service Manual frames discovery as understanding the problem, users, constraints, improvement opportunities and measures of success before committing to build. It also treats stopping as a valid result when the evidence does not support further investment.
- A problem statement that identifies the affected user, current behaviour and business consequence.
- A map of the core workflow, including offline steps, exceptions and people who operate or support it.
- A record of the evidence reviewed, the gaps that remain and the assumptions that still need testing.
- A technical context map covering current systems, data, integrations, ownership and relevant constraints.
- A risk and dependency list with an owner or next test for each material unknown.
- A recommended next decision: stop, research further, test a prototype, buy an existing product or scope implementation.
- If implementation is recommended, a bounded first release with exclusions and acceptance evidence.
Does discovery include design or development?
Discovery can include sketches, data checks or small technical experiments when they answer a named uncertainty. It should not quietly become the build. GOV.UK separates discovery, which investigates the problem, from alpha, where teams test possible solutions and their riskiest assumptions. That distinction helps buyers see whether they are purchasing evidence or implementation.
| Activity | Discovery when | Implementation when |
|---|---|---|
| Interface sketch | It helps a user or stakeholder react to a workflow assumption | It becomes a production design with states, accessibility and handoff detail |
| Technical prototype | It tests one feasibility risk and can be discarded | It must be maintained, secured, monitored and supported |
| Data sample | It reveals structure, quality or migration constraints | It becomes a repeatable migration with validation and rollback |
| Integration check | It confirms access, documentation and a critical capability | It handles production authentication, failures, limits and monitoring |
How should you compare discovery proposals?
Put the proposals side by side using the question each engagement will answer. A lower fee can be appropriate for a narrower question. It is not automatically cheaper if the supplier excludes the evidence needed for the next decision.
- Write the decision you expect to make when discovery ends.
- List the user groups, workflows, systems and constraints included in each proposal.
- Ask who will gather evidence and who must be available from your organisation.
- Ask which artefacts you will own and whether another supplier can use them.
- Check whether assumptions, exclusions and unresolved questions will be visible.
- Separate optional implementation from the discovery fee.
- Confirm how the supplier will recommend stopping when further work is not justified.
When can you skip a paid discovery phase?
Skip a separate discovery engagement when the important evidence already exists and the next unit of work is genuinely bounded. A documented change to a known system may need a technical review and written implementation scope rather than a broader product discovery.
- The primary user, workflow, exclusions and acceptance checks are already agreed in writing.
- The relevant repository, data, integrations and account ownership are accessible and understood.
- The requested change does not depend on unresolved policy, compliance or cross-team decisions.
- A qualified team can estimate the work without hiding major assumptions inside the quote.
Do not skip evidence work merely because a supplier offers a fixed implementation price. If the underlying workflow or technical boundary is unknown, the uncertainty still exists; it has only moved into contingency, change requests or delivery risk.
What should you ask before paying for discovery?
The best questions expose the boundary and the handover. They also reveal whether the supplier is prepared to reach an answer that does not create a larger project for them.
- Which single decision is this engagement designed to support?
- What evidence will you collect rather than assume?
- Who must participate, and what access is required before the work starts?
- Which systems, workflows, user groups and compliance questions are excluded?
- What will I receive, in which format, and who owns it?
- How will unresolved risks and disagreements be recorded?
- Could the recommendation be to stop, buy or narrow the project?
- What would make the discovery price change after acceptance?
How does ApexStack scope a Product Blueprint?
The Product Blueprint starts from US$1,000 and turns one product or technical question into an evidence-based scope and next decision. Before work begins, the written proposal states the problem, the agreed output, the people or systems that must be accessible, the exclusions and the decision the output should support.
When the evidence supports implementation, a Launch Sprint starts from US$2,500 for one tightly scoped first release or core workflow, covering planning, UX direction, implementation, testing and deployment. Authentication, billing, mobile applications, advanced AI, multiple integrations, data migration, compliance and extensive administration can increase the quote.
Sources
- How the discovery phase works — GOV.UK Service Manual
- User research in discovery — GOV.UK Service Manual
- Measuring the benefits of your service — GOV.UK Service Manual
- The Product Discovery handbook — Atlassian
Frequently asked questions
- What is a reasonable software discovery phase price?
- There is no reliable universal amount or percentage. A reasonable price is tied to a written boundary: the user groups, workflows, systems and risks being investigated; the evidence and artefacts you will receive; and the decision they enable. ApexStack’s bounded Product Blueprint starts from US$1,000.
- Should discovery be fixed-price or time and materials?
- A fixed price can work when the question, access requirements, deliverables and exclusions are genuinely bounded. Time and materials can fit open-ended research, but it should still have a decision goal, review points and a spending boundary. The contract shape matters less than whether uncertainty is visible.
- How long should software discovery take?
- The purpose should determine the duration. Reviewing one known workflow can be smaller than researching a multi-channel service with legacy systems and regulatory constraints. Ask the supplier to connect the schedule to the evidence they need, rather than accepting a universal timeline.
- Is discovery part of the build cost?
- Discovery and implementation purchase different things. Discovery pays for evidence and a decision; implementation pays for a working, supportable release. A supplier may credit or package fees commercially, but the proposal should keep the deliverables and boundaries visible.
- Can I take the discovery output to another development company?
- You should confirm that before buying. Useful outputs record evidence, decisions, assumptions, exclusions and technical context in formats another qualified team can review. Provider-specific tooling may still need access or export arrangements, so ownership and handover belong in the proposal.
How ApexStack can help with tech stack consultancy
A tech stack consultancy engagement turns an expensive technical decision into an inspectable recommendation. ApexStack reviews the product goal, current architecture, team capability, security, ownership, operating constraints and total cost before recommending what to keep, change or test next. The output is written for the decision-maker, with assumptions, trade-offs, evidence gaps and a practical action sequence made explicit. Share the decision, constraint or workflow behind your project and we will help you define a sensible next step.