Software Project Discovery Phase: Reduce Risk Before Development

A software project often starts with a sentence that sounds specific enough to build: replace the spreadsheet, add an AI workflow, connect the customer portal to the operational system, or launch the first version before a funding deadline. Each sentence hides decisions about users, data, permissions, integrations, ownership, and what success will look like. A software project discovery phase makes those decisions visible before they become expensive code.

My practical rule is to investigate the assumptions capable of changing the project. Discovery should leave a team with a clearer workflow, a smaller set of technical risks, evidence from focused experiments, and an explicit next investment decision. The work has earned its cost when a founder can decide to build, narrow the scope, run another experiment, buy an existing product, or stop.

What a software project discovery phase should decide

Discovery begins with the business pressure behind the proposed software. A founder may need to test a product idea before runway becomes tight, an operations team may be losing hours to manual reconciliation, or an existing application may be blocking a new revenue stream. That pressure determines which questions deserve attention and which can wait for implementation.

The team then needs to describe one complete workflow. Who starts it, which information enters the system, what decision or action occurs, and what useful result comes back? This is the same boundary I use when scoping an MVP, because a collection of requested features provides much less guidance than an end-to-end user outcome.

A useful discovery should support a concrete decision. The available options need to be explicit before the investigation begins. Writing them down also prevents development from becoming the default answer:

• Is software required to solve this problem?
• Which user and workflow belong in the first phase?
• Which assumption creates the greatest product risk?
• Which integration, data source, or operating constraint creates the greatest technical risk?
• What needs to be proved before estimating the full build?
• Who will own the software after launch?

These questions keep the work attached to the reason the project exists. They also give discovery an ending, since the team can stop when it has enough evidence to make the agreed decision. Move questions with no effect on that decision into delivery planning.

Start with assumptions that could invalidate the project

Every proposed product contains assumptions. Some concern user behaviour, such as whether an operations manager will trust an automated recommendation. Others concern implementation, such as whether a third-party API exposes the data needed to produce that recommendation within an acceptable time.

The useful first step is to write those assumptions down and rank them by consequence and uncertainty. An assumption deserves early investigation when being wrong would change the workflow, remove the expected value, or force a different architecture. Familiar implementation details can remain part of delivery planning because proving them during discovery would add little information.

Product assumptions

Product assumptions describe the people, problem, behaviour, and expected value. Interviews, observation, prototypes, and manual service experiments can test them without requiring a production application. If the main uncertainty is whether anyone needs the workflow, a technical build will usually produce weaker evidence than direct contact with likely users.

For example, a purchase-approval product might assume that approval delays come from missing status visibility. Watching the current process may reveal that requests actually stall because nobody knows which budget owner has authority. That finding changes the workflow before architecture or interface work begins.

Technical assumptions

Technical assumptions concern feasibility, cost, reliability, security, and ownership. A discovery may need to verify API access, inspect sample data, measure a representative query, confirm identity requirements, or trace how an existing system behaves. The investigation should target the uncertain mechanism and produce evidence another engineer can inspect.

The GOV.UK Service Manual recommends understanding users, constraints, possible improvements, and measures of success during discovery. That is a useful general frame. A software project also needs enough technical investigation to reveal whether the intended service can be built and operated within those constraints.

Investigate the highest-risk technical path

A technical spike is a small implementation used to answer a feasibility question. It may authenticate against a vendor API, move one sample record through a data pipeline, deploy an empty service into the target environment, or test whether a search index supports the required filtering. The spike needs a question and a success condition so that its output remains evidence with a defined limit.

During my work with ChatSheet AI, the product direction changed across several MVPs while useful backend patterns for content ingestion, CMS integrations, and vector-based retrieval carried forward. That distinction matters during discovery. Product assumptions can continue moving while focused technical work establishes which parts of the system are feasible and reusable.

A thin end-to-end path is especially useful when several systems must cooperate. It can prove that the team has access to the required accounts, that data can move through the intended boundaries, and that a change can reach a realistic environment. This often reveals operational constraints that architecture diagrams leave comfortably invisible.

The spike should remain disposable unless the team deliberately raises it to production quality. Authentication shortcuts, synthetic data, manual deployment, and missing failure handling may be reasonable for an experiment. Recording those shortcuts prevents the delivery team from mistaking experimental code for a safe foundation.

Produce decision-ready outputs

Discovery outputs vary with the decision, although a practical package usually contains a small set of connected artefacts. Each one should explain what was learned and how that learning affects the build. A longer document adds no value when nobody can trace its contents to scope, risk, or ownership.

A focused discovery package can include the outputs below. The exact set should follow the risks investigated during the work. Each output must help somebody make or execute a decision:

The architecture direction should remain proportional to the evidence. A discovery can identify likely service boundaries, data ownership, and deployment constraints without fixing every framework or infrastructure choice. The startup technology stack framework becomes useful once the team understands who will maintain the product and which constraints the stack must satisfy.

Estimates should also show their confidence. A small range may be credible for a proven workflow with known integrations, while a broad range or staged commitment is more honest when a dependency remains unresolved. Discovery improves an estimate to the extent that it resolves those important unknowns.

When a separate discovery phase is unnecessary

Some work is already understood well enough to enter delivery. A minor extension to a familiar application, a repeated integration using an established pattern, or a clearly defined regulatory change may need a short technical conversation and normal implementation planning. Turning every change into a formal phase would delay useful work and produce repetitive artefacts.

The relevant test is whether unresolved questions could materially change the plan. When the workflow, technology, dependencies, and operating model are familiar, the team can record the few remaining assumptions and begin. Discovery can also happen inside the first delivery milestone when a small experiment and the initial production path are naturally the same work.

There is also a reasonable concern that discovery becomes paid indecision. That happens when workshops continue without a named decision, every possible future receives equal attention, or the provider has an incentive to produce a large proposal. A time boundary, ranked assumptions, and explicit exit criteria keep discovery focused on reducing risk.

A compact discovery checklist

Before committing to the full build, I would want the team to answer the following questions. The answers should be specific enough for product and engineering stakeholders to challenge. Any unresolved answer needs an owner and a reason it can safely wait:

• What business pressure makes this project worth considering now?
• Which user completes the first valuable workflow?
• What evidence will determine whether the project continues?
• Which product assumption could remove the expected value?
• Which technical assumption could force a different plan?
• Have we tested the most consequential integration or data path?
• Which security, reliability, and support requirements form the production floor?
• What has been explicitly excluded from the first phase?
• Who owns unresolved decisions?
• Can the team explain why it should build, narrow, investigate, buy, or stop?

A discovery phase is complete when those answers support the next commitment. Some projects will need interviews, technical spikes, and a phased architecture, while smaller projects may reach the decision in a few focused sessions. The amount of work should follow the uncertainty in the project.

MBV Labs provides technical leadership and hands-on engineering for focused project work. If you have an ambiguous software goal and need to turn it into a practical build decision, you can share the project and its largest uncertainty. A focused discovery can establish the next commitment before a larger build begins.