What is a software discovery phase and why does it come before code?

Discovery should make the next investment decision clearer. Record the problem, known evidence, delivery constraints and the assumptions that could change whether to build, buy, reduce the scope or stop. It can reduce avoidable rework, but no universal saving in weeks or months follows from running it.

Wavect’s Discovery + Roadmap offer is for a product direction that is sufficiently clear to plan delivery. The published offer is EUR 3,500 fixed, excluding applicable VAT, with a 2 to 3 week duration; the fee is credited in full against the build invoice if you continue with Wavect. Architecture, milestones and a fixed-price build offer are the core outputs. Access, client decisions and the signed scope govern the work.

If demand is still untested, discuss early product validation first. Plan a decision-changing experiment where useful, but agree recruitment, interviews, prototype creation, usability sessions and technical test execution explicitly. A planning engagement does not automatically include every experiment it recommends.

Leave with a decision record, not a feature wish list

Write one page naming the buyer, the user’s job, the current workaround, one complete target journey and the budget boundary. Add the riskiest assumption, what evidence would change the decision and who can approve scope. Keep commercial demand separate from technical feasibility: a working API proves neither willingness to pay nor repeat usage.

Divide the backlog into must, defer and kill. Must contains the smallest complete journey and the controls needed to operate it safely. Defer contains useful additions that do not test the current assumption. Kill contains ideas rejected by evidence or incompatible with the budget, with a reason. “Kill” removes a feature from this scope; it need not ban reconsideration if evidence changes.

Before booking a prototype test, name the pending decision and write down what you will do for each outcome. If an integration is the main unknown, first check whether the provider will grant sandbox access, whether representative data is available and who can approve its use. When evidence cannot be obtained before sign-off, record the dependency, its owner and when it can be tested. GOV.UK’s service manual puts focused prototypes for risky assumptions in its alpha phase. That is a useful model for scoping the experiment separately. GOV.UK alpha guidance.

Worked example: a maintenance-request portal

This is a proposed, separately scoped research exercise, not an automatic deliverable of the fixed planning offer. A clickable prototype can test comprehension and workflow; production authorization and routing require implementation-level tests.

Illustrative, not a Wavect client result. Hypothesis: building managers can submit a complete maintenance request without a coordinator retyping it. Test: give five representative managers a clickable prototype and realistic sample requests; observe submission and the coordinator’s triage without coaching. Illustrative threshold agreed before testing: four of five complete the required fields unaided, and no request is routed to the wrong property. This small sample checks workflow usability; it does not establish market demand or a statistically reliable success rate.

Must: identify the property, describe the issue, confirm submission and route it to the responsible coordinator with access controls. Defer: native apps and automated supplier recommendations. Kill for this scope: a public supplier marketplace that does not test the request workflow. If the threshold fails, revise and retest; if the underlying problem is not valuable, stop. If it passes, scope a limited operational pilot rather than declaring product-market fit.

Make acceptance and changes explicit

For each must-have, record starting state, action, expected result and a failure case. Add integration assumptions, data ownership, dependencies, non-goals and the person accepting delivery. A new feature must replace agreed scope or receive an explicit cost and schedule decision. The handover includes findings and unresolved questions so another team can use the work.

The GOV.UK discovery guidance is a useful reference for understanding the problem before committing to implementation. Its moderated usability testing guide explains observing representative tasks. The example thresholds above are our illustrative planning choices, not requirements from those sources. Sources checked 11 November 2026.