Before a software project is quoted or built, a good partner will want to understand your business first. That step is often called a discovery phase. Here is what it involves, what you should walk away with, and how to tell a useful one from a sales exercise.
Why start with discovery at all
Most software projects that go wrong don't fail because the code was bad. They fail because the wrong thing was built, or the right thing was built for an imagined version of the business. Discovery exists to close that gap before money is spent on development.
It is most valuable when the project is large, when it replaces several existing tools, or when you aren't sure yet what you need. If you are buying a standard product off the shelf, you probably don't need one.
What happens in a discovery phase
Formats vary between companies, but a sound discovery phase covers the same ground.
1. Your objectives
What is the business trying to achieve, and how will you know the software has helped? "Win more repeat customers" is something a project can be measured against. "Modernise our systems" is not.
2. Your users
Who will actually use the software: your team, your customers, your suppliers? What do they do all day, and where do they get stuck? The people doing the work usually know things the people paying for it don't.
3. Your existing systems
Which tools do what today, where does data get copied by hand, and what would break if one of them changed? This is also where you find out what is worth keeping.
4. The shape of a solution
Only then does the conversation turn to features and technology: which features matter most, in what order they should be built, and what the software needs to be built on so that it stays secure and affordable to run.
What you should get at the end
A discovery phase that ends in a conversation and a quote isn't much use. You should receive something written down that you can read, challenge and keep. A useful one typically produces:
- User personas, describing who the software is for and what they need from it.
- A prioritised feature map, showing what to build first and what can wait.
- Technical architecture recommendations, explaining what the software should be built with and why.
At Digital Nature, this is called the Strategic Blueprint, and it is yours to keep whoever builds the product. That last point matters. If the document is only useful to the company that wrote it, you are paying for a sales pitch rather than a plan.
How to tell a good one from a poor one
- It involves the people who do the work. If only the owner is in the room, important detail will be missed.
- It is allowed to change the plan. A good discovery sometimes shows that the project should be smaller, staged differently, or not bespoke at all. If the answer is always "build everything", be wary.
- The output is portable. You could hand it to another supplier and they could price the work.
- Technology is chosen on evidence. A track record and long-term support are better reasons than fashion.
- It talks about the end of the project too. Who looks after the software after launch, and how will you be kept informed along the way?
Questions to ask before you agree
- Who will be in the workshop, and who do you need from our side?
- Can it be done online or in person?
- What exactly will we receive, and do we own it?
- What happens if the discovery shows the project isn't worth doing?
- Who maintains the software once it is live?
Getting the most from it
Discovery rewards preparation. Before the workshop, gather the things that show how the business really runs: the spreadsheets people rely on, the tools you pay for, and a list of the jobs that frustrate your team most. Bring the people who use those tools every day, not only those who sign off the budget.
Be honest about what doesn't work, including processes you are not proud of. A plan built on a tidied-up picture of the business will fit the tidied-up version, not the real one.
A hypothetical example
Imagine a business that runs customer records in a CRM, orders in a spreadsheet and invoices in a separate accounts tool. The owner believes the answer is a new CRM. In discovery, the team mapping the work finds that the real problem is re-keying orders into invoices. The prioritised plan puts that single connection first, and leaves the CRM until later. The business avoids replacing a tool that was never the problem.
That outcome is the point. Discovery is cheaper than building the wrong thing.
Is it worth doing?
For anything beyond a small, well-understood job, yes, provided it produces a document you own and a plan you could take elsewhere. Treat it as a way of making the build decision with better information, not as a commitment to build.