Custom software discovery: what to decide before estimating a first release

Make the estimate answer a specific decision

“We need a service platform” leaves an estimator to guess the users, workflow and dependencies. Before asking for a delivery estimate, decide what the first release must make possible and what evidence supports that choice. You can still request an early budget range, provided its assumptions remain visible.

The discovery brief is the record behind that estimate. It should explain why the proposed scope is useful, which boundaries are agreed and what remains unresolved. More pages do not necessarily make it more reliable. One unanswered access requirement can matter more than a complete screen list.

Follow one request before specifying the platform

Consider a hypothetical facilities team planning a custom service-request platform. Staff report a problem; a coordinator asks for missing details, assigns a technician and checks that work is complete. The proposed business outcome is that the coordinator can identify the next responsible person for every open request without chasing separate messages.

In this example, a walkthrough reveals that requests sometimes arrive without a location, and technicians contact the coordinator to learn whether an assignment is still current. Those observations suggest problems to investigate. They do not yet prove that every employee needs a new account or that automatic dispatch will help.

Bring representative requests, the people who handle them and access to the relevant systems. Record where information came from. A manager’s account of the process, an operator’s demonstration and a verified system capability support different conclusions.

Keep evidence and assumptions in different columns

Test the unknowns that could change the scope

Prioritize an unknown by its consequence. If technicians cannot use the platform on site, the roles and workflow change. If a label is unclear, the interface may need a smaller adjustment. Test the former before refining every screen. Update the record with the result, its limits and the decision taken.

The GOV.UK Service Manual separates discovery, which investigates the problem and constraints, from alpha, which uses prototypes to test risky assumptions. Commercial teams use these labels differently. Agree whether the engagement includes interviews, prototypes, technical checks and a revised estimate; do not assume that the word “discovery” promises all of them.

Distinguish a verified hard constraint from a preference. In this example, unavailable system access may block the proposed connection; a preferred screen layout can change. Identify who can confirm or relax each constraint. If AI-assisted request classification is proposed, give it a separate test and decision. The core intake workflow should not silently depend on an untested capability.

Draw a boundary that leaves a usable workflow

Suppose the checks support starting with the coordinator’s team and direct technician updates. The proposed first release receives a request, holds incomplete items for clarification, records assignment and lets a technician report completion for coordinator review. Requesters can see their own request status. The team still needs to confirm the operating limits, access rules and support responsibilities.

Automatic dispatch, contractor billing and historical reporting stay outside this release. Asset lookup remains conditional on verified access. If that check fails, a maintained location list is an alternative only if the operations lead accepts responsibility for keeping it current. An exclusion should state how the work will happen meanwhile.

Describe the outcomes that will show the scope works

GOV.UK describes acceptance criteria as outcomes used to confirm a user need has been met. For this proposed release, agree checks such as these before estimating the implementation:

• A request with no usable location stays visible for clarification and cannot be assigned.
• A reassigned request shows the current technician; the previous technician can no longer update it.
• A technician’s completion report waits for coordinator review before the request is shown as closed.
• A requester can follow their own request but cannot open another requester’s record.

Attach the estimate to its conditions

Ask for an estimate against the dated scope and acceptance checks, with dependencies and unresolved assumptions alongside it. Separate implementation from any remaining investigation. Include the work needed to introduce the release, such as account setup, data preparation and training. Explain who supplies each input.

For a remaining uncertainty, record what finding would trigger a revised estimate. If direct technician updates fail the device test, coordinator entry is a different scope requiring review. An unexplained contingency amount does not tell the sponsor which decision they are funding.

Close discovery with a decision

The sponsor should leave with a decision and its evidence. Discovery can legitimately end without a build; GOV.UK explicitly recognizes stopping as an outcome. Use the brief to choose the next commitment:

• Proceed when the first scope is useful, feasible enough to estimate and owned by the operating team.
• Test when a named uncertainty could still overturn the proposed workflow or estimate.
• Reduce when a smaller release remains useful and the team accepts the work left outside it.
• Stop when the evidence does not justify the change or a necessary constraint cannot be resolved.