A software discovery phase is a short, structured piece of work done before development begins. The team maps your users, workflows, data and integrations, then writes a prioritised scope with a reliable estimate. It saves money because mistakes found on paper cost a conversation to fix, while the same mistakes found in code cost weeks of rework.
Think of it as the survey before building an extension. Nobody enjoys paying for it, and almost everyone is glad they did.
What actually happens in a discovery phase?
Discovery is a series of focused conversations and small investigations that turn "we need a system for X" into a document a team can build from. It usually involves the people who will use the software, not just the person paying for it.
Typical activities:
- Stakeholder interviews. Short sessions with owners, managers and frontline staff about how work really gets done.
- Process mapping. Drawing the current workflow step by step, including the spreadsheets, WhatsApp messages and sticky notes holding it together.
- User roles and permissions. Listing every type of user and what each may see and do.
- Data review. Looking at existing records to judge what can be migrated and how much cleaning it needs.
- Integration checks. Confirming that the tools you rely on (payment gateways, accounting packages, CRMs, messaging platforms) actually offer the connections you assume.
- Risk spikes. Small technical experiments on the riskiest part, such as an unfamiliar API or an AI feature, before anyone commits to a price.
- Prioritisation. Sorting features into must-have, should-have and later.
For a small internal tool this can be a couple of working sessions. For a multi-role platform it may run for a few weeks. GRWW starts every fixed-price software quote with a discovery call for exactly this reason.
Which problems does discovery catch early?
Discovery mostly catches wrong assumptions: about users, data, integrations and what "done" means. Each one is cheap to fix early and expensive to fix late.
| Assumption that turns out wrong | Found in discovery | Found mid-build |
|---|---|---|
| "Our accounting software has an API for that" | Adjust the plan or pick another approach | Stalled features, redesign, extra cost |
| "There are only two types of user" | Add roles and permissions to the scope | Rework screens, database and access rules |
| "Our data is clean" | Plan a cleaning step and migration rules | Launch delayed while records are fixed |
| "Everyone does the process the same way" | Agree one process, or design for variants | Staff reject the software after launch |
| "Reports can come later" | Capture the few reports that are critical | Missing data that was never stored |
| "It needs to be an app" | Test whether a mobile-friendly web app works | Paying for two app stores you did not need |
Every row on the right-hand side is a change request you pay for. Every row on the left is a line in a document.
What should you receive at the end?
A good discovery ends with deliverables you own and could take to any developer. If all you receive is a price, it was a sales call, not discovery.
Expect most of these:
- A scope document describing the problem, users, features and what is out of scope.
- User roles and permissions, written down.
- Process maps of the current and future workflow.
- Prioritised feature list with must-haves clearly marked.
- Wireframes of the key screens, at least for complex flows.
- Integration and data notes, including any risks found.
- A technical approach: proposed stack, hosting and how the system will be deployed.
- An estimate and plan: a fixed price or a narrow range, with milestones and assumptions.
The scope document often grows into a full requirements document. Our guide to writing a software requirements document includes a template you can use yourself.
How does discovery save money in practice?
It saves money in three ways: it removes rework, it shrinks the first release, and it turns guesses into a fixed price. The third one matters more than people expect.
- Less rework. Wrong assumptions are found before code depends on them.
- A leaner first version. When features are listed and weighed side by side, the nice-to-haves become obvious. Many projects come out of discovery smaller and cheaper than they went in.
- Pricing you can trust. Without discovery, a supplier either pads the quote to cover unknowns or quotes low and recovers through change requests. With discovery, the unknowns are mostly known, so a fixed price becomes realistic. Our comparison of fixed price, time and materials and dedicated team contracts explains why that matters for risk.
There is a fourth, quieter benefit: discovery is a low-risk way to see how a team thinks and communicates before you commit a full budget.
How long does discovery take, and how is it priced?
Discovery usually takes from a few days to a few weeks and is often sold as a small, fixed-price piece of work. Length depends on how many user types, integrations and unknowns are involved.
- Small internal tool: a few sessions over a week or so.
- MVP or customer portal: often one to three weeks.
- Multi-role platform with integrations: several weeks, sometimes including technical spikes.
Some suppliers include a light discovery in the project price; others charge separately and credit part of it against the build. Ask how it works, and confirm that you own the outputs either way.
When can you skip or shorten discovery?
You can keep discovery very light when the project is small, the requirements are already written and nothing technical is uncertain. Even then, someone should confirm scope in writing.
Discovery can be brief when:
- You are adding a small, well-defined feature to an existing system.
- You already have detailed requirements and designs from a previous exercise.
- The work is a straightforward integration between two well-documented tools.
Do not skip it when there are several user types, unfamiliar integrations, data migration, compliance requirements or AI features. Those are the projects where surprises are most likely and most expensive.
How should you prepare for discovery?
Arrive with evidence of how work happens today; it makes discovery faster and the estimate more accurate. You do not need a polished brief.
Useful things to bring:
- Screenshots or copies of the spreadsheets and forms in use now.
- A list of the tools the software must connect to, with logins for test access where possible.
- Two or three examples of software you like, and why.
- Numbers: how many users, records, transactions or enquiries per month.
- Your budget range and any hard deadlines.
- The names of the people who do the work daily, so they can join a session.
Once discovery is done, the build follows the stages described in our step-by-step guide to the custom software development process. Costs, contracts and ownership are covered in our guide to building custom software as a growing business.
Frequently asked questions
Is a discovery phase just a way for agencies to charge more?
It can be if it produces nothing useful. A genuine discovery leaves you with a scope document, priorities, wireframes and an estimate you own and could take elsewhere. If you would not be able to use the outputs with another team, ask what you are paying for.
Can I do discovery myself?
You can do much of the groundwork: map your process, list users and features, and gather data samples. A developer still needs to check integrations, data and technical risks before giving a reliable price, so expect at least a short technical review.
What if discovery shows the project is not worth building?
That is a good outcome, because you found out cheaply. Discovery sometimes shows that an existing SaaS product, a simple integration or a process change will solve the problem. Paying a little to avoid a large mistake is the point.
Does discovery fix the price completely?
It should give you a fixed price or a narrow range for the agreed scope. If you later add features or the assumptions change, those changes are priced separately. That is normal, and the written scope makes those conversations straightforward.
Who from my business should take part?
The decision-maker, someone who understands the budget, and one or two people who do the work every day. Frontline staff often reveal the exceptions and workarounds that matter most.
Begin with a conversation
If you have a system in mind but are unsure what it should include or cost, discovery is the natural first step. Tell us what you want to fix and who it is for, and we will start with a discovery call and then a fixed-price quote. You can also read about what we build.