Many software projects go wrong long before anyone writes code. They go wrong because nobody properly understood the problem. A discovery phase exists to fix that, at a point where changing direction costs almost nothing.
What discovery is for
Discovery turns "we think we need an app" into a clear, shared understanding of the problem, the people affected, the constraints, and the smallest useful thing to build first. It reduces risk and replaces assumptions with evidence.
What typically happens
Conversations with the people who do the work. Not just the person commissioning the project. The staff who live with the problem often know the details that matter most.
Walking through the current process. How does the work happen today, step by step? Where does it get stuck? What do people do to work around it?
Looking at the systems and data involved. What already exists, what needs to connect, and what state is the information in?
Identifying risks. Compliance, security, awkward integrations, change management. The things that can derail a project if found late.
Prioritising. Separating "must have" from "would be nice", and deciding what the first release should include.
Testing ideas cheaply. Sketches or clickable prototypes of key screens let people react to something concrete before it is built.
What you should get at the end
- A plain-language statement of the problem and the goal.
- A map of the process as it works now, and how it should work.
- A prioritised list of features, with the first release clearly defined.
- Prototypes of the important screens.
- A plan, a proposal and estimates that rest on real understanding.
How long does it take?
It depends on the size of the problem. For a focused business problem it is often a matter of days to a couple of weeks, not months. The aim is just enough investigation to make good decisions, not to produce a binder nobody reads.
Why it is worth paying for
A proposal written without discovery is a guess with a price on it. A proposal written after discovery rests on facts. The cost of discovery is usually small compared with the cost of building the wrong thing. It also lets you test the working relationship before committing to a larger project.
How to prepare
- Write down the problem in a sentence (our guide to writing a software brief helps).
- List the people who are affected and make time for them.
- Gather examples: the spreadsheet, the form, the report people rely on.
- Be honest about the mess. Discovery works best when nothing is hidden.
What if discovery says "don't build"?
Occasionally discovery shows that an existing product will do the job, or that the process needs fixing before any software helps. That is a good outcome. You have saved the cost of building something unnecessary. (We cover that decision in custom software vs off-the-shelf.)
Curious how this would work for your situation? Get in touch or read about our approach.