What Is a Discovery Phase in Software Development, and Is It Worth Paying For?

Most software projects that go over budget did not fail during the build. They failed earlier, when a team started coding on a short description and only later found that the founder, the designer and the developers had each pictured a different product. A discovery phase exists to find those differences while they are still cheap to fix.

In this guide I explain what a discovery phase is, what it should produce, how long it takes, when it is worth paying for and the warning signs that a discovery is not giving you value.

What a discovery phase is

Discovery is the stage where you and the development team answer the questions that decide what gets built: who the users are, what problem the first release solves, which features are in and which wait, how the main flows work and what technology fits. Public bodies use the same idea. The UK government's service manual describes how the discovery phase works as understanding the problem before committing to build anything.

It is not a long research project, and it is not a sales meeting. It is focused work with a clear end: documents and designs good enough that a team can estimate the build with confidence.

What you should get at the end

The names vary between companies, but a useful discovery should leave you with most of the following:

If a discovery ends with only a slide deck and a price, you paid for a sales proposal.

How a discovery phase usually runs

1. Kick-off workshop. The founder or product owner walks the team through the idea, the customers and the business model. Everyone writes down their open questions.
2. Research. Short interviews with a few target users, a look at competitors and, for internal tools, time with the people who do the work today.
3. Scoping. The feature list is cut down to one first release. This is the step that saves the most money.
4. Design of the main flows. Wireframes or a simple prototype of the screens that matter most, tested with a few users where possible.
5. Technical checks. Confirm that integrations, payment providers, data sources or old systems behave the way the plan assumes.
6. Plan and estimate. Milestones, a timeline and a cost built on everything above, plus a list of known risks.

The Nielsen Norman Group's overview of the discovery phase in UX is a good read if you want more detail on the research side.

How long it takes

For most first releases, discovery takes one to four weeks. What moves it towards the longer end:

• Several user types, such as customers, vendors and admins in a marketplace.
• Integrations with payment gateways, ERPs, government systems or hardware.
• An existing system to replace, where the hidden rules live in old code and in people's heads.
• Regulated data, such as health or financial records.
• Many people who need to agree on the scope.

Discovery should be a small part of the whole project. If it starts to feel like the project, the scope is probably too big for a first release.

When it is worth paying for, and when it is not

A paid discovery makes sense when:

• Your idea is clear in your head but not written down.
• Quotes from different companies are far apart, which usually means each one imagined a different product.
• You plan a fixed-price contract, which only works when the scope is written and agreed.
• You are replacing a system your business depends on, like a custom ERP.
• You need to show investors or a board a clear plan before you commit.

You can usually skip a separate paid discovery when the product is small, you already have a written scope or PRD, or you are building a quick prototype or proof of concept to learn something fast. In those cases a careful review during the proposal is enough.

Warning signs to watch for

• No clear outputs. If the company cannot list what you will receive, ask before you pay.
• You do not own the documents. The PRD, designs and technical notes should be yours once paid for, so you can take them to any team.
• No end date. Discovery should have a fixed length and a fixed fee, agreed upfront.
• Discovery that only confirms the original idea. Good discovery removes features and raises hard questions. If nothing changed, little was examined.
• The build is assumed. You should be free to take the outputs elsewhere if the fit is wrong.

How to prepare for discovery

You will get more from any discovery, paid or free, if you bring:

• A one-page description of the problem, the customer and how you will make money.
• Two or three products you like, and what you like about each.
• The must-have features for launch, and the ones you would cut if you had to.
• Any existing systems, data or contracts the new product must work with.
• A budget range and a target date, even rough ones.

For a first view of budget, try the app cost calculator or look at the project cost breakdowns before you start.

How we approach it

At Creuto, every project starts with a free 30-minute strategy call, and you get a clear written proposal within 24 hours. For a small, well-defined product, that is often all the planning needed before we start, and the first working version typically follows in about 4 weeks. For a larger or less certain product, I recommend a focused discovery first, so the scope, screens and technical plan are agreed before anyone fixes a price. Either way, your code lives in your own accounts from day one. See our product strategy and PRD service and rapid prototyping.