A software discovery phase should leave you able to make a better investment decision. Buy a documented understanding of the problem, a tested view of important uncertainties, a defined first release and an evidence-based delivery proposal. Workshops and attractive screens are activities; the deliverables must remain useful after the workshop ends and even if another engineering team builds the product.
This matters when a Canadian operations team commissions a European supplier, or when a founder in Portugal needs a product team before hiring internally. Distance makes undocumented assumptions harder to notice. Discovery should expose those assumptions while changing direction is still relatively inexpensive.
Begin with the decision discovery must support
Write one sentence describing the decision at the end of the engagement. For example: “Decide whether to replace our spreadsheet dispatch process with a customer portal, extend our existing platform, or retain the current process while fixing its integration.” This is a hypothetical example, not a project result.
That framing keeps discovery open to a smaller solution. Ask the supplier to identify who approves the decision, which users can provide evidence and what information they need from your team. An inaccessible database, absent process owner or unavailable integration vendor should appear as a dependency immediately.
A useful discovery agreement also defines its boundary. It might investigate one dispatch workflow and its reporting, while excluding payroll and route optimization. Record what happens if interviews reveal a second business problem; it should become an explicit scope decision.
Require evidence of how the work happens
A feature list is an incomplete description of a business. Ask for a process map showing the trigger, users, decisions, data and completion conditions. Include exceptions: rejected requests, missing details, conflicting records, manual approvals and the work performed outside the main application.
The evidence pack can be compact:
- ▸A description of the current workflow, reviewed by someone who performs it.
- ▸An inventory of inputs, outputs and systems that own each important record.
- ▸User roles and the actions each role may perform.
- ▸Representative examples of difficult cases, anonymized where appropriate.
- ▸Baseline measures that the organization can actually collect.
- ▸Open questions with an owner and a proposed way to resolve them.
For the dispatch example, “reduce administration” is too vague to evaluate. “Measure the time from a complete request to a confirmed dispatch, including manual corrections” provides a testable starting point. Discovery need not promise an improvement percentage to be useful.
Separate a prototype from technical proof
A clickable prototype can reveal whether users understand a workflow. It cannot establish that a difficult integration works or that historical records can be migrated accurately. Commission the right experiment for the uncertainty.
If the main risk is an external scheduling API, request a small technical investigation using an authorized test environment. Its output should document access requirements, available operations, rate limits, example responses and unresolved constraints. If the risk is user comprehension, review the prototype with representative users and record where they hesitate.
Agree what happens to experimental code. Some investigations are intentionally disposable. If the supplier expects to reuse a component in production, it needs an explicit review and acceptance path. Otherwise, a quick proof can quietly become an unsupported foundation.
Make architecture a decision record
The architectural deliverable should explain the proposed application boundaries, data stores, identity approach, integrations and operating environment. Ask why those choices fit the business constraints, which alternatives were considered and which decisions can safely wait.
Security requirements belong here. The NIST Secure Software Development Framework provides a shared vocabulary for incorporating security practices into development and acquisition. Use that vocabulary to ask who owns requirements, verification and vulnerability handling; referencing a framework is not evidence that a supplier has implemented it.
For cross-border delivery, record where production data resides, who can access it remotely and which subcontractors or services may process it. The European Commission's transfer guidance and standard contractual clauses are relevant inputs where applicable. A discovery report should flag the required review, rather than casually declaring the whole arrangement compliant.
Turn the first release into something testable
The first-release backlog should connect each item to a user need and an acceptance condition. “Build reporting” is not enough. Specify who sees a report, its source records, permitted filters, refresh expectations and how totals will be checked.
Request explicit exclusions alongside the backlog. They prevent a reasonable future ambition from being mistaken for a current contractual commitment. Separate launch requirements from experiments and later enhancements.
The estimate should reveal its assumptions, dependencies and uncertainty. Ask for a breakdown across design, engineering, integration, migration, testing, release and handover. Where a range is broad, the supplier should identify what evidence would narrow it. Use the quote comparison worksheet to normalize the subsequent proposals.
Accept discovery with a walkthrough
At the final review, have someone outside the discovery team explain the proposed release using only the deliverables. Missing context becomes visible quickly. Walk through a normal case, an exception and a failure of an external dependency.
Accept the phase when you receive editable artifacts, documented decisions, unresolved risks, the prioritized release scope and a clear next-step recommendation. That recommendation may be to build, investigate one remaining uncertainty, adapt an existing product or stop. Its value comes from the evidence behind it.
For supplier selection before this phase, use the software development vendor scorecard. For help turning a workflow into a scoped engagement, explore software engineering services and send the workflow and constraints for review.