What is project discovery? Explained with an architect's brief
Discovery is the short research stage before a software project is built: learning who it is for, the real problem and the limits. Explained with an architect's brief written before any plans.
- Author
Umair Mateen- Published
- Updated
- Reading time
- 5 min
- Category
- Process
In one sentence: Discovery is the short research stage at the very start of a software project, where the team learns who the product is for, what problem it must solve and what limits apply, before anyone designs or builds anything, so you only pay to build something worth having.
The everyday picture
Imagine you want a new house. A good architect does not start drawing on day one. First they sit with you and ask questions. Who will live here? How do you spend your mornings? Do you need room for a grandparent later?
Then they visit the land. They check the slope, the sun and the local building rules. Some things can bend, like where the kitchen goes. Some cannot, like the law on how close you can build to the road.
Everything they learn goes into a written brief. Only then does anyone draw plans. Discovery is that brief, for software.
Discovery is the architect's brief. Before anything is built, the team questions the idea, studies the people and the rules involved, writes down what it learned and then decides whether to go ahead.
How it works, step by step
- Start with the problem, not the solution (the architect asks why you want the house). Teams often arrive with an answer already in mind, such as "we need an app". The UK government's service guide advises questioning that answer and turning it back into a problem to understand.
- Research the people who will use it (asking who will live in the house). The team talks to customers or staff, watches how they do the task today and maps the steps around it, not just the part the software would touch.
- Find the limits (checking the land and the building rules). The team lists what is fixed, such as a law or a system that cannot be replaced, and what is only habit and could change.
- Write the brief (the architect's written brief). The findings become a short summary: the real need, the limits, a list of ideas worth testing and how success will be measured.
- Decide what happens next (build, change the plan, or walk away). The next stage, which the UK guide calls "alpha", tests ideas with rough, throwaway prototypes. Discovery may also show that a simpler fix, like clearer instructions, is enough.
Try it · Myth or fact
Project discovery: myth or fact?
Decide for yourself first, then tap each statement to check it.
0 of 3 checked
Where the picture stops
- A house brief usually ends in a house. A software discovery can honestly end with "do not build this". The UK guide says stopping at the end of discovery is not a failure.
- A house is built once. Software keeps changing after launch, so teams keep learning from users. Discovery is the first and most focused round of that learning, not the last.
- An architect visits one plot of land. Software discovery often looks across several teams, existing systems and other services the user already relies on.
Why it matters for your business
- Less money spent on the wrong thing. Finding out that users need something different is far cheaper on paper than after months of building.
- Fewer surprises later. Rules, old systems and data limits are found early, instead of halfway through the project.
- A clear go or no-go. You decide whether to invest based on evidence, not on the loudest opinion in the room.
- A known timeframe. Discovery is short by design. The UK guide says around 4 to 8 weeks is typical for its projects, though a problem nobody has studied before can take longer.
An example
Imagine a 20-person accounting firm that wants a customer app, because clients keep phoning to ask where their tax return is.
In discovery, the team talks to a handful of clients and the staff who answer the phones. They find most calls ask one question: "Have you received my documents?" They also learn the firm's main software cannot be replaced, which is a fixed limit.
The brief suggests testing something smaller first: an automatic email when documents arrive and when the return is filed. The firm tests that idea with a simple prototype before deciding whether a full app is still needed.
Frequently asked questions
Is discovery the same as gathering requirements?
Not quite. Requirements describe what to build. Discovery comes first and asks whether to build anything at all, and why, by studying users and the problem.
Does anything get built during discovery?
No. The UK government's guide says you should not start building in discovery. Rough prototypes come in the next stage, to test ideas cheaply.
How long does discovery take?
It depends on how big and how well understood the problem is. The UK guide says around 4 to 8 weeks is typical for its services; small projects can be shorter.
What do I get at the end?
A clear picture of the problem and the people affected, the fixed limits, a ranked list of ideas to test and a way to measure success, plus a decision on what to do next.
Related explainers
- Frontend vs backend, explained with a restaurant
- What is an API? Explained with a waiter in a restaurant
- What is cloud hosting? Explained with a serviced office
The DevDrift starts web and SaaS projects with a short discovery before any code is written: see how.
Sources
Could you explain this to a colleague now?
Mark it and posts that mention it will show a tick. Saved in this browser only.