A software discovery phase turns a business problem into a decision about what to build, what to test first and what the first release should cost. Its value is the uncertainty it removes before a larger development commitment.
For a founder commissioning an MVP, discovery should end with material that another team could inspect: evidence about users, an agreed first-release scope, important constraints and an estimate with assumptions. A presentation full of screens is useful only if it helps you make those decisions.
This guide explains the deliverables to ask for, how to recognise unfinished discovery and how to use the results when comparing development proposals.
When does a project need discovery?
Discovery is useful when uncertainty could change the architecture, scope or commercial case. That includes a new workflow, several user roles, an unfamiliar integration, a migration from existing software or disagreement about the first audience.
A small, familiar feature in a system your team already understands may need a short planning session rather than a separate engagement. A complex replacement product may need investigation across several departments. Set the depth by the decisions at risk.
The GOV.UK Service Manual describes discovery as understanding the problem before committing to a service. Its public-sector process is not a startup schedule, but the distinction is useful: researching a problem and delivering a production system are different commitments.
Start with a decision, not a feature catalogue
Suppose a small business wants to replace appointment scheduling by email. The first question is whether a booking link would solve the real problem. If most appointments require an individual price negotiation, a generic calendar may automate the wrong step.
A useful discovery goal would be: decide whether a limited booking product can reduce scheduling work for a particular group of consultants, and identify the smallest pilot that can test it. This is an illustrative scenario, not an EmphaSoft client result.
Write down the decisions that need answers: which users to recruit, whether payment is part of the first journey, which calendar integrations are essential and what would make the project uneconomical. These decisions give research and technical investigation a clear purpose.
What should a discovery phase deliver?
| Deliverable | What it should contain | Decision it supports |
|---|---|---|
| Problem and user evidence | Observed workflows, interview findings and assumptions still untested | Whether the proposed solution addresses a meaningful problem |
| Core journey | Actors, steps, exceptions and the useful outcome | What the first release must deliver end to end |
| Scope and exclusions | Included work, deferred features and manual alternatives | What the estimate covers and what it does not |
| Technical constraints | Integrations, data sources, access rules and operational dependencies | Which risks need a prototype or technical experiment |
| Estimate and delivery approach | Work breakdown, uncertainty ranges, responsibilities and dependencies | Whether to fund the next phase |
| Acceptance and learning plan | Release criteria, pilot measures and review points | How to judge delivery and product value separately |
These can be concise documents. A small pilot does not need a large specification, but the people approving it need enough detail to understand its limits.
Separate evidence from assumptions
Keep a short record of what the team knows, what it infers and what remains unknown. For example, interviews may show that consultants spend time coordinating appointments. That does not prove they will maintain another calendar or pay for a booking service.
For each important assumption, assign an owner and a way to investigate it. A user test can explore whether people understand a confirmation screen. A technical spike can check an integration. A paid pilot can test a commercial offer. Use the smallest investigation that can change the decision.
Our PoC, prototype and MVP comparison explains those options. Avoid commissioning a full application when the unresolved question could be answered with a smaller experiment.
Define scope that can be estimated
List the user journeys, roles, data and external services that the first version needs. Include errors and operational work. For the booking example, deciding how to prevent conflicting reservations matters as much as drawing the availability screen.
Record exclusions explicitly. If calendar synchronisation is deferred, explain how pilot consultants will keep availability accurate. If the workaround is not practical, the integration belongs in the scope. A deferred feature needs a credible alternative, not just a label.
Use our worked guide to MVP feature prioritisation to turn the journey into release decisions. Keep acceptance criteria close to each included item so the estimate and the release review refer to the same behaviour.
How to evaluate a discovery estimate
Ask for the effort and uncertainty behind the total. A useful estimate identifies design, implementation, testing, deployment and coordination work. It also states what the client must provide and how long external approvals or access might take.
Check whether the estimate includes data migration, third-party subscriptions and support during the pilot. Those costs can sit outside the development invoice while still being necessary to launch.
Require the team to identify which assumptions would change the estimate materially. An unfamiliar API, missing data or unresolved identity model should be visible. Our software development cost guide explains how scope and engagement models affect the budget.
What should you retain after discovery?
Agree access to research notes, designs, the backlog, technical findings and any experimental code. Identify material that belongs to an existing platform or supplier separately. The practical goal is that your next delivery team can understand the decisions and continue the work.
Discovery can end with a decision to pause, narrow the audience, use an existing product or run another experiment. That can be a valuable outcome when the original build would have addressed the wrong problem.
If you proceed with the same supplier, use the deliverables to agree the next scope and review points. If you compare suppliers, give each the same material. Our development company checklist helps evaluate how teams handle evidence, uncertainty and handover.
Questions to ask before commissioning discovery
- Which decisions will we be able to make at the end?
- Who will participate from product, design and engineering?
- How will the team reach real users rather than relying only on stakeholder opinions?
- Which technical risks will be investigated, and which remain outside scope?
- What documents and working files will we receive?
- How will unresolved questions affect the next estimate?
Frequently asked questions
Is discovery the same as writing a specification?
No. A specification records intended behaviour. Discovery investigates which behaviour is worth building and what could prevent it from working. A specification may be one output, but it cannot replace the investigation.
Do we need polished designs before estimating an MVP?
Not always. Clear user flows and constraints may be enough for an initial range. Use more detailed prototypes where interaction uncertainty could change the scope or invalidate the idea.
Can discovery have a fixed budget?
Yes, if the investigation, participants and deliverables are bounded. Agree what will remain unknown when the budget is reached and how that affects the next decision.
Prepare the first conversation
Bring the business problem, the intended users, any existing research or code and your main constraint. EmphaSoft's startup development teams can help define a first release and a delivery approach. If you want to discuss what your project needs to establish before development, tell us about your product.