A discovery phase is a short, separate piece of work done before a software or website build to find out what exists, what is wrong, and what should be built. It ends with written documents: an audit, a scope, and specifications. You need one when the project is too large or unclear to plan in a page.
Most of our projects start with a one-page plan. You describe the problem, we write back with what we would build and what we would leave out, and work begins. For a small, clear job that is all the planning anyone needs.
Some projects do not fit on a page. There is an existing site nobody has fully mapped, or a business process that lives in three people's heads, or a build with enough parts that guessing at the scope would be irresponsible. Those projects get a discovery phase first.
Discovery has a poor reputation because it is sometimes sold as weeks of workshops that end in a slide deck. Done properly it is short, and it ends in documents you could hand to any developer.
What is a discovery phase?
A discovery phase is a defined block of work at the start of a project whose only output is understanding, written down. It looks at what exists today, identifies what is wrong or missing, and specifies what should be built. No production code or final design is produced during discovery.
The key word is "written". A discovery phase that ends with a conversation has produced nothing you can keep. The documents are the product, and they should be useful even if you never speak to the same developer again.
What happens during discovery?
During discovery, a developer inventories what already exists, measures it against what the business needs, and writes specifications for the work. On a website that means crawling every page. On software it means walking through the real process with the people who do it and recording each step.
Our work for Rebalanced by Rita, a Scottsdale aesthetics practice, started this way. Before building anything we did three things in order:
- A crawl. Every page on the existing site, collected by software, so the plan was based on what was there and not on what anyone remembered being there.
- An honest audit. What was working, what was not, and what was missing.
- Written specifications. One for each page type: treatment pages, pages for the concerns those treatments address, and pages for the cities the practice serves.
Only then did we build. Treatments, concerns, and cities are all cross-linked by script, so no page is orphaned. Linking like that depends on knowing the page types up front, which is what the specifications provided.
What should you get at the end of a discovery phase?
At the end of a discovery phase you should receive documents, not impressions. The standard set is an inventory of what exists, an audit of its problems, a scope stating what is in and out, specifications for each part, and a plan with cost and timeline for the build.
- An inventory. Every page, screen, data source, or step in the current process.
- An audit. What is wrong, ranked by how much it matters.
- A scope. What will be built and, just as useful, what will not.
- Specifications. For each page type or feature: what it contains, where its data comes from, and how it connects to the rest.
- Open questions. Decisions only the business can make, listed so they get made.
- A build plan. Cost and timeline for the work the documents describe.
If a discovery proposal does not list its deliverables, ask for the list before agreeing to it.
Do you need a discovery phase?
You need a discovery phase when the project cannot be scoped honestly in a single page. Signs include a large existing site, a process that has never been written down, several systems that must connect, or stakeholders who disagree about the goal. Small and clear projects do not need one.
| Situation | Discovery needed? |
|---|---|
| New site for a business with a known list of services and locations | Usually not. A one-page plan covers it. |
| Rebuilding a large existing site | Yes. A crawl and audit at minimum. |
| Software that replaces a manual process | Often. The process has to be written down first. |
| A single well-defined tool or automation | Usually not. |
| Several people with different ideas of the goal | Yes. Discovery forces the decision. |
Being told you do not need discovery is a good sign. A developer who recommends a paid planning phase for a five-page site is selling process.
What does discovery look like for custom software?
For custom software, discovery means documenting how the work is done today before designing how software will do it. Someone sits with the people who do the job, records each step, each exception, and each document produced, and turns that record into a specification for screens and data.
The AZLG Case Hub handles intake, a client portal, document generation, and e-signature for a personal injury practice. A training binder of 17 modules was written alongside the software. Software for a professional practice encodes how that practice works, so the procedure has to be on paper somewhere. Writing it down early is cheaper than discovering it through bug reports.
If your project is software, our guide to writing a software project brief will get you partway through discovery on your own.
Is discovery worth paying for separately?
Discovery is worth paying for separately when its documents would be valuable on their own. A good audit and specification let you compare quotes from several developers on the same basis, and they reduce the unknowns that make a fixed price risky for both sides.
It also limits your commitment. You pay for a small, defined piece of work and see how the developer thinks before agreeing to the larger one. We explain how this interacts with pricing in fixed price vs hourly.
The trade-off is time. Discovery delays the first working software. For a project where the scope is already clear, that delay buys nothing.
Frequently asked questions
How long does a discovery phase take?
It depends on how much there is to look at. A site audit and specification is a much smaller job than documenting an entire business process. Ask for the duration in writing along with the deliverables, and be wary of discovery with no end date.
Who owns the documents produced in discovery?
You should. Confirm it before you start. The point of discovery is that the audit and specifications are yours to use with any developer, including one you have not met yet.
Can I do discovery myself?
Partly. You can list your services, describe your process, and gather examples of the documents you produce. A developer adds the technical inventory, such as a full crawl, and the judgment about what is practical to build.
Is discovery the same as a free consultation?
No. A consultation is a conversation to see whether there is a fit. Discovery is paid work that produces documents. Be cautious if the two are blurred.
If you are not sure which kind of project you have, describe it to us. We will say plainly whether a one-page plan is enough.