The Software Discovery Phase: What You Get in Two Weeks and Why It Pays

If you have searched for “what is discovery in software development”, you have probably been handed a proposal with a line item called discovery and no clear idea of what it buys. The short version: discovery is a fixed, short piece of work done before the build, whose output is the information you need to decide whether, how and in what order to build. It is a low-cost point in a project at which to find out you are wrong.

This post explains what a discovery phase involves, what it produces, what it does not, and how to tell a good proposal from a padded one. It draws on the productised discovery engagements we run, which are typically two weeks long.

Why discovery lowers risk early in a build

Most software projects go wrong in the same few places: the scope was never pinned down, an integration turned out to be harder than assumed, a stakeholder nobody interviewed had a veto, or the estimate was built on a feature list rather than a plan. Each of these costs a little to find in week one of a project and a lot to find in month four.

Discovery moves those findings forward. You pay for a small team to spend a couple of weeks asking awkward questions, looking at the existing system and writing down what they find, instead of paying a whole build team to find out the same things by trial and error. That is also why we treat discovery depth as one of the biggest drivers of what a project costs, as we cover in our guide to website costs in Australia.

What we ask you for before it starts

Discovery moves quickly only if the inputs arrive early. Typically we ask for:

• Access to the current site, app or system, including an admin login and any staging environment.
• Existing documentation, even if it is out of date: brand guidelines, previous briefs, architecture diagrams, supplier contracts.
• Analytics and any user research you already hold.
• A list of stakeholders and users we should speak to, with someone who can book their time.
• The names of any third-party systems the project touches (payments, CRM, ERP, identity, hosting) and a contact for each.
• A short statement of why you are doing this now, in outcomes rather than features.

Missing inputs are not a reason to wait. They become findings: “no one holds the hosting credentials” is a risk worth knowing about in week one.

Workshops and stakeholder interviews

The first part of a discovery is people, not code. Our discovery work typically starts with:

• Requirements workshops with the people who will use and approve the product. The aim is to separate the outcome someone needs from the feature they have already decided on.
• Stakeholder interviews, usually one to one, because the person who will not say it in a group is often the one who knows where the problem is.
• Current-state journey mapping, following a real user through today’s process to find the steps that cost time, cause errors or drive people away.
• Problem statements, one sentence each, agreed with you before we draw anything. If we cannot agree on the problem, no wireframe will fix it.

On discovery work for ACS, the American Chemical Society, the work covered the author and reviewer flows for a new dashboard, along with the wireframes and build specification that fed the AI journal recommender we then built.

The technical audit of the existing system

Where something already exists, we audit it. That means mapping the assets in use, who hosts what, how the pieces talk to each other, and which integrations are fragile. On one discovery for an auction platform, the work included a current-state and future-state technical architecture and a staged project plan, and part of the existing platform was hosted by a third party.

An audit usually looks at:

• Code quality, framework versions and known security exposure.
• Data: where it lives, how clean it is, and what has to be migrated.
• Integrations: each one’s owner, authentication method, rate limits and failure behaviour.
• Hosting, deployment and monitoring.
• Constraints that sit outside your control, such as a vendor’s styling limits on a hosted shop template.

For Standards Australia, the discovery ran about two weeks and produced requirements, current-state journey mapping, a sitemap, design and technical specifications and an itemised plan for the follow-on phases. Their Digital Standards Web App followed.

What a discovery delivers

A discovery should end with documents you can act on, not a slide deck of impressions. Here is what we typically hand over, who it is for, and the question each one answers.

Deliverable	What it answers	Who uses it
Scope and prioritised backlog	What are we building first, and what can wait?	Product owner, delivery team
Sitemap and user flows	How will people move through it?	Designers, content owners
Wireframes or clickable prototype (where the interface is central)	Does this actually work for the people using it?	Stakeholders, users, designers
Architecture and integration plan	How does it fit with what we already run?	Technical lead, IT, security
Risks register	What could derail this, and what do we do about it?	Sponsor, project manager
Estimate range	Roughly what will this take, and what moves the number?	Finance, sponsor
Phased roadmap	In what order, with what dependencies?	Sponsor, delivery team

Two of those deserve a comment. The estimate is a range with stated assumptions, because at this stage honest numbers have a spread, and the assumptions tell you what to challenge. The prototype is included where the interface carries the risk, such as a portal with several user roles. For a back-office integration with a thin interface it is wasted effort, and a good proposal says so.

What discovery does not give you

Being clear about limits stops disappointment later.

• A fixed price for the whole build. A range with assumptions is what the evidence supports. A fixed price comes after the open questions are closed, and sometimes only after the first phase.
• Working software. A prototype shows the flow; it is not the product, and it should not be shipped.
• Certainty about the future. Discovery lowers the odds of surprises. It does not remove them.
• A decision made for you. It produces the information. Choosing to proceed, phase it or stop is still yours, and “stop” is a legitimate and cheap outcome.
• A replacement for ongoing product thinking. Priorities change as users touch the product. The backlog is a starting point.

How to judge a discovery proposal

When you compare proposals, look for these signs:

1. Named deliverables. “Workshops and analysis” is a process; “scope, architecture, risks register, estimate range, phased roadmap” is a deliverable. You should be able to picture the documents.
2. A fixed shape. A defined duration and team, with a stated number of feedback rounds, beats open-ended hours.
3. Named people and roles. Who is in the room? Look for a technical lead and a designer, not only a project manager.
4. Time with your users. Discovery that never speaks to the people who will use the product is a desk exercise.
5. A technical audit when something exists. If you have a live system, the proposal should say how it will be examined.
6. Output you own. Check you receive the documents in full and can take them to another supplier.
7. A next step. Good discoveries end with an itemised proposal for the next phase, including what is excluded. Our how we engage page covers how we scope and quote work.

Be wary of discovery that is really a sales stage with a fee attached, where the findings only make sense if the same supplier builds. Equally, be wary of one that costs so little it can only be a template.

When you can skip it

Discovery is not compulsory. You can reasonably skip or shrink it when:

• The project is small, well understood and reversible, such as a brochure site on an established platform with content already written.
• You are repeating something you have built before, with the same team and the same stack.
• A previous phase already produced current specifications, and little has changed since.
• The real uncertainty is only technical and one short spike will settle it.

Skip it when the cost of being wrong is low, not because the schedule is tight. A rushed brief is the usual way a two-week saving turns into a two-month delay.

Getting started

If you are weighing a build and not sure how much discovery it needs, send us what you have. We will tell you whether it warrants the full two weeks, a lighter scoping pass, or whether you can go straight to build.

Sources: this post draws on the scope and deliverables of our own discovery engagements, including the ACS and Standards Australia projects, checked November 2026. No vendor documentation was relied on.