Direct answer: Custom software discovery should produce a clear problem definition, a mapped workflow, the main constraints and risks, a prioritized first scope, and evidence for the build decision.
Custom software discovery should give a team enough evidence to make a responsible build decision. It is not a long document produced before anyone speaks to users. It is a focused investigation of the problem, the workflow, the constraints and the outcome the software must support.
For a delivery path that connects discovery to implementation, see custom software development and our software product development guide.
Start with the business decision
Define what must improve and how the organization will know. A request for a new portal may really be a need to reduce manual handoffs, improve customer visibility or remove errors from an operational process. Discovery should distinguish the requested solution from the underlying job.
List the people who use, approve, support and depend on the process. Observe or map their current work, including exceptions and workarounds. The UK Government Service Manual’s discovery guidance frames discovery around understanding a problem and deciding whether a service should move forward. The GOV.UK alpha guidance shows how to test risky assumptions and constraints before full delivery.
Deliver a usable workflow map
A workflow map should show the trigger, major steps, systems, handoffs, decision points and failure paths. Keep it specific enough to expose where data is duplicated, where a person must intervene and which parts of the process are stable enough to automate. The map should make scope discussions concrete.
Describe the first release
Agree on the smallest complete journey that creates value. Separate essential capabilities from later improvements. Include the administrative and support functions needed to operate the release, not only the customer-facing screens. Record the assumptions the first release will test and the measures that will show whether it worked.
Surface technical and delivery constraints
- Integrations: Identify source systems, API access, data ownership and failure behavior.
- Data: Note migration, quality, retention and permission requirements.
- Security: Define roles, sensitive actions, audit needs and relevant compliance obligations.
- Operations: Specify hosting, monitoring, support and release responsibilities.
- Dependencies: Record decisions or access that must come from other teams or vendors.
End with decisions, not a stack of slides
A useful discovery package contains a clear problem statement, prioritized workflows, first-release scope, success measures, key risks, architecture direction and a delivery plan with explicit assumptions. It should also say which questions remain open and what evidence will resolve them. With those decisions made, design and engineering can proceed without repeatedly rediscovering the same constraints.
Frequently asked questions
What should a discovery phase deliver?
It should deliver a shared view of users and workflows, the decisions that remain open, the principal technical and delivery risks, and a first scope with acceptance criteria.
When is discovery complete?
Discovery is complete when the team has enough evidence to choose the next delivery step and can state what must be tested during implementation.
