Software discovery phase: when do you need one?
Decide whether your app needs a software discovery phase. Learn which questions to investigate, what deliverables to expect, and when a scoping call is enough.
By Chase Poirier · Updated · 8 min readPaying for discovery should buy a decision you can make. I would ask which unknown prevents a responsible build quote before paying for a software discovery phase. Use that question to define the investigation, its outputs, and its stopping point.
Start with the unknown that changes the decision
A vendor integration may be undocumented. Your app may depend on data you do not yet have permission to use. A workflow may rely on expert judgment that nobody has described clearly. These are specific reasons to investigate.
Ask what would change if the assumption proved wrong. If it could change feasibility, scope, or the commercial commitment, it deserves attention before a fixed build quote. A long list of features alone does not prove you need a separate discovery engagement.
Decide whether the uncertainty needs research, a decision, or a smaller scope
Suppose your product must read job records from software used by local contractors. You have seen a vendor demo, but you do not know whether customer accounts include API access. A builder cannot responsibly promise the integration based on the demo alone. Access rights, available fields, and the way updates are retrieved could change the product.
Compare that with uncertainty over the color of an approval button. That is a design decision you can make during normal product work. Or consider a requested reporting feature that nobody needs for the pilot: deferring it may remove the uncertainty without a separate research engagement.
Write the consequence beside every unknown. If the finding would change whether you build, the scope you fund, or a dependency you promise customers, it is a candidate for bounded discovery. If the answer would not change the next commitment, ask why you need to pay for it now.
Make discovery a bounded piece of work
Before starting, identify what must be learned and how the team will investigate it. Agree on access and input required from you, as well as what the work will leave unresolved.
Discovery can include a workflow review, a technical test, or a proposed first-release plan. Those activities should follow the actual questions rather than a standard package of documents nobody needs.
| Unknown | Possible investigation | Decision it informs |
|---|---|---|
| Can the app retrieve required records? | Inspect vendor access and test a representative connection. | Proceed, change the workflow, or remove the dependency. |
| What must the first customer accomplish? | Map the workflow and review a proposed release boundary. | What to include in the build. |
| Can an existing prototype support the next milestone? | Review relevant code and critical workflows. | Keep, revise, or replace specific parts. |
An example integration investigation with a clear end
This illustrative discovery brief investigates contractor job records. It does not include the customer-facing app, a complete integration, or a market study. Its purpose is to learn whether the first release can obtain the records the customer needs.
The founder would need an authorized test account and a contact who can confirm the customer access arrangement. The developer would need representative records, including an incomplete job and a changed job. Agree what happens if the vendor cannot provide access; a provider should report that limit rather than quietly replace the investigation with unrelated design work.
| Item | What to agree |
|---|---|
| Decision | Can the first release rely on this vendor connection, or should it start with a file import? |
| Test | Retrieve an authorized sample of jobs and check the required fields and update behavior. |
| Evidence | Record access used, sample results, errors, and differences between documentation and observed behavior. |
| Limit | A sample test does not establish production reliability or access for every future customer. |
| Exit | Recommend an integration, a narrower workflow, a manual import, or a pause; explain unresolved conditions. |
Ask for outputs you can use
A useful output names findings, evidence, remaining assumptions, and recommended next steps. It should make the build decision clearer. A polished presentation with no resolved question is difficult to act on.
Clarify ownership and handover terms before work begins. If you want the option to take the findings to another builder, say so and agree on an output that makes that practical.
For example, an integration finding can state which record types were retrieved, which permissions were used, what failed, and what still needs testing. That gives the next builder something they can inspect, rather than a conclusion they have to accept on trust.
Before approving discovery
- The questions and boundaries are written down.
- The fee and required founder input are agreed.
- Findings distinguish tested facts from assumptions.
- There is a proposed next step and a reason for it.
- Ownership and handover terms are clear.
Read the findings as a record of what was actually checked
An actionable finding could say: the test account can retrieve job IDs and scheduled dates; completed-job notes are unavailable through the tested endpoint; the vendor has not confirmed access under the intended customer plan. Those facts lead to a different build decision from a slide saying the API is available.
Ask for the tested environment and the relevant input/output examples in a form you are permitted to retain. Request clear labels for observed facts, vendor statements, and assumptions. Any test scripts or prototypes need an explanation of their limits and agreed handover terms.
A recommendation should connect the finding to your options. Starting with a customer-uploaded file could allow a useful pilot while vendor access is resolved, but someone must prepare that file and handle errors. The alternative is part of the decision, including its business cost.
Discovery does not establish customer demand by itself
A successful integration test shows that a connection worked under the tested conditions. It does not prove people want to buy the product. A prototype can help explore a workflow without proving a sustainable business.
Keep product feasibility, customer evidence, and the financial decision separate. If discovery uncovers a reason to pause or use an existing tool, that can be a useful result.
Keep customer evidence separate from technical discovery
Bring the customer conversations, commitments, or existing workflow that led you to the idea. A technical investigation can tell you whether a connection works; deciding whether the opportunity deserves investment also requires evidence from the people you expect to buy.
TheShop can help shape the product and identify technical unknowns. Do not assume a discovery engagement includes market validation, recruiting users, or a guarantee that the product will sell. Agree on the questions and responsibilities before paying.
Keep a separate decision for whether customers will use it
A contractor saying that a dashboard looks useful is different from agreeing to connect an account and use it during a real job. The latter raises operational questions: who grants access, what information can be shared, and what the contractor will do if the app is unavailable. Capture those commitments separately from the integration findings.
GOV.UK’s discovery guidance starts with understanding user needs and constraints before committing to a service. That principle is useful here, but its government delivery phases and typical durations are not TheShop packages or timelines. Your investigation should be sized to the actual decision.
When the work ends, hold a decision review with the person who controls the budget. Which assumption changed? Is the first customer result still achievable? What has to be true before the next payment? Proceeding to development is one possible outcome; a smaller release or a decision to pause may protect the budget just as well.
How we approach it at TheShop
The initial scoping call is free. When the work is clear enough, we can quote the build with product definition included. When material investigation is needed first, we propose bounded paid discovery.
Bring your product vision, budget range, intended users, and known dependencies. We will discuss whether they are clear enough for a build proposal or need investigation first.
Read what's included in Vision to LaunchCommon questions
Do I need discovery before building an app?
You need investigation when an unresolved issue could materially change the scope, price, or delivery approach. An uncertain integration or complicated permissions model may justify it. A familiar workflow with accessible systems may be clear enough to scope directly. Ask what specific decision discovery will enable before agreeing to a separate paid engagement.
What should a software discovery phase deliver?
The deliverables should match the uncertainty: a tested integration, agreed workflow, prototype, or written scope with checked assumptions. Specify what you will receive and what remains unresolved. You should be able to use the output to decide whether to build, change the approach, or stop, even if a different provider performs the eventual development.
Does software discovery validate an app idea?
Technical discovery can establish whether an approach works under tested conditions. It does not establish that customers will buy the product. Customer conversations, pilot participation, and payments supply different evidence about demand. Keep a separate record of what prospective customers have actually committed to, and decide whether business uncertainty needs attention before technical investigation.
Write down the question you need answered
Describe the unknown, what would change if the assumption failed, and what evidence would let you decide. Add it to your product brief before buying discovery.
Prepare a product brief