Discovery Phase decoded: What $800 and 1–2 weeks actually buy you

A short Discovery Phase does not buy you a finished product, and it does not buy you a guarantee that the scope will never change. What it buys you is a structured starting point — and at the beginning of a software project, that is worth more than it sounds.

By Nataliia Molochii, Business Analyst at NERDZ LAB

In this article:

• What you actually get at the end
• The core deliverable: turning an idea into an FBL
• What the 1–2 weeks actually look like
• The client does not need to remember everything
• A familiar integration can still hide complexity
• Discovery gives you an estimate — not a promise
• Discovery does not freeze the product
• What happens if you skip Discovery?
• AI has changed what clients bring into Discovery
• So what do $800 and 1–2 weeks actually buy you?

Before Discovery, a project usually exists as a business idea, a few documents, some competitor references, an AI-generated specification, or simply a sentence: “We need a portal where tenants submit maintenance requests and property managers track them.” That is enough to explain the idea. It is not enough to start building it with any confidence.

A short Discovery — the kind that costs around $800 and takes one to two weeks — turns that sentence into a scope the client, the business analyst, the project manager and the development team can all work from. The goal is not to document every detail of the future product. It is to understand what is actually being built, break it into manageable pieces, estimate them, flag the unclear areas and create a baseline for development.

Here is what that looks like in practice, based on the Discovery phases we run for our clients.

What you actually get at the end

The exact set of deliverables depends on what is agreed before Discovery starts, but a standard engagement leaves you with four things:

• Feature Breakdown List (FBL) — the product decomposed into modules, epics and use cases, with the notes and nuances collected from our conversations.
• Full scope and MVP scope — the same FBL marked up to show what belongs in the first release and what comes later.
• Technology stack — a short description of the proposed stack, reviewed by our technical team.
• Estimate — hours per feature, with the assumptions behind the numbers visible.

Depending on the project, Discovery can also include:

• a list of risks and assumptions
• a high-level roadmap
• wireframes or a clickable prototype
• a full competitor analysis: a detailed comparison of competing products, with proposals for functionality they lack or handle poorly. A brief overview of what is already on the market and how it works is part of the FBL work in any case

These are agreed at the start, because each of them changes how much time the phase needs.

Everything produced during Discovery belongs to you. If you decide not to continue with us, that is your decision — you leave with a properly done Discovery that any development team can pick up and start from.

What you bring, what Discovery does, and what you leave with

The Core Deliverable: Turning an idea into an FBL

For most projects, the central output of Discovery is the Feature Breakdown List.

An FBL decomposes the product from large areas of functionality into units that can later become development tasks and user stories. The authentication module from one of our FBLs, anonymised, looks like this:

A fragment of a real FBL, anonymised

This structure sounds simple, but it changes the conversation. “Users need to log in” is a requirement. “Users can sign up with an email or phone number and a password, with a one-time code, or through Google or Facebook” is something a team can discuss, estimate and eventually implement.

The FBL normally represents the full scope of the product. If the client needs an MVP, the same document separates MVP functionality from the broader scope; on larger projects, functionality can also be divided into future releases. That makes the FBL useful long after Discovery ends: it becomes one of the core working references during development.

What Discovery does not need to produce is a deep technical architecture document. Our technical specialists take part where their input is needed — estimation, feasibility, the stack — but the purpose of this type of Discovery is to understand and structure the product, not to design every technical component in advance.

What the 1–2 weeks actually look like

“One-to-two-week Discovery” can sound as though the client spends ten working days in workshops. In practice, most of that time is analysis, not meetings. A typical run looks like this:

1. Before the kick-off. Once the Discovery agreement is signed, the client sends whatever they already have — pitch decks, notes, competitor references, an AI-generated spec. The BA/PM works through all of it before the first call.
2. Kick-off call. This goes one of two ways. With a client who has little written down, it is a conversation: they tell us how they see the product, and we ask questions. With a client who arrived with documents, we often come to the call with a rough draft FBL already and use it to structure the discussion.
3. Analysis between calls. The BA/PM breaks the scope into modules, epics and use cases, identifies what is missing, makes assumptions where necessary and prepares specific questions.
4. Second call. By now there is a working version of the FBL. We walk through it with the client, add nuances, correct assumptions and agree on the MVP boundary.
5. Client approval. The client reviews the agreed FBL and confirms it. Only the approved version goes to estimation, so the numbers are attached to functionality the client has signed off on, not to our assumptions.
6. Estimation and delivery. Our technical team reviews the approved FBL, estimates it and confirms the stack. The client receives the FBL, the scope split, the stack and the estimate — and another call if anything needs clarifying.

Six steps, usually two substantial calls

Two substantial calls cover most projects; complicated ones take three or four. The number depends on the client as much as on the project: some people explain their ideas in a highly structured way, others need targeted questions to reveal the details behind what they describe. A client who can talk for an hour about everything they have imagined is not a problem either — more material gives us more to structure, prioritise and challenge.

The questions themselves are the clearest sign that Discovery is working. Instead of “What else should the platform do?”, the conversation becomes: “Can this user edit a campaign after it has been sent?” “Which social providers do we need for login?” “Does this role see all deals, or only deals assigned to them?” “Is this part of the MVP or a later release?” That is where a vague product idea starts becoming buildable.

The client does not need to remember everything

Clients routinely forget functionality. That is normal: they are describing a product that contains dozens or hundreds of individual decisions, and nobody holds all of them in their head at once.

User roles are the classic example. On one project we had defined six roles with the client and were several calls into detailing what each of them could do. Then, on an unrelated call, the client mentioned in passing that a certain feature “also goes to role number seven.” There was no role number seven. It had never come up. The client had simply forgotten it existed — and it was a role with its own permissions, its own screens and its own share of the estimate.

Caught during Discovery, that is a conversation and a few more rows in the FBL. Caught during development, it is a scope and timeline discussion.

Part of the BA/PM’s job during Discovery is to know the common gaps and ask about them before the client remembers on their own: the admin panel, notifications, permissions, an integration the client already uses elsewhere and did not think to mention. Roles are not equally important on every project — in a simple app they take a few lines; on a platform where administrators, customers, managers, brokers or vendors all have different capabilities, roles can become one of the main elements defining the scope. Discovery is the moment to find that out while the assumptions are still cheap.

A familiar integration can still hide complexity

Integrations are another place where a requirement looks simpler than it is. Stripe is our favourite example.

One of our clients was building a marketplace for second-hand clothing: people list their items, other users buy them, and all money movement goes through Stripe. “Payments via Stripe” went into the initial FBL as a single, familiar line — and it turned out not to be one. Stripe offers several account models, and not every one of them supports what a marketplace with money moving between individual sellers and buyers actually needs. The project required a specific account type and a specific setup, and that only became clear once we dug into how funds were meant to flow between participants, not from the label “Stripe integration.”

The integration was still “Stripe.” The implementation behind that label was significantly different from the initial assumption. This is one reason estimates produced during Discovery cannot be treated as guarantees: the purpose of Discovery is to reduce uncertainty, not to pretend it has disappeared.

Discovery gives you an estimate — not a promise

One of the most important things we explain to clients during Discovery is that a software estimate is conditional.

We can examine a feature, clarify its expected behaviour and have developers estimate it. That does not mean every technical complication is visible before implementation begins. Some complexity only appears when a developer starts working with the real API, the real data, a legacy system or an edge case. A feature estimated at 20 hours may turn out to need 30, and that does not automatically mean Discovery failed. What matters is what happens next.

With a structured Discovery, there is already a feature description and an original estimate. We can go back to the client and say: this is what we estimated; this is the technical issue we found during implementation; this is why it adds roughly ten hours; and these are the ways to proceed.

When an estimate decreases, there is rarely any conflict. When it increases, documentation is what keeps the conversation factual. An estimate is only useful when its reasoning is visible — in the proposal and, just as importantly, months into development.

Discovery does not freeze the product

There is a misconception that a detailed Discovery should prevent scope changes. It does not, and it is not meant to. Products evolve, clients change their minds, users give feedback, new opportunities appear. What Discovery gives the project is a baseline.

Back to the second-hand clothing marketplace. The original FBL covered one thing: users sell their items and ship them to buyers. Some way into the project, the client decided that users should also be able to rent their items out. On the surface that sounds like an extra option on a listing. In practice it is a completely different kind of interaction, with its own flow, its own statuses and its own payment logic.

Without a baseline, that discussion can quickly turn into: “But wasn’t this always supposed to work this way?” With the FBL, it was much clearer. We could show what had originally been discussed, identify exactly what was new, estimate it and present it as an expansion of scope — explaining why, to use illustrative numbers, selling and shipping had been estimated at 100 hours and the platform now needed closer to 200.

That is transparency for the client as much as protection for the team. The change is not an arbitrary extra cost: they can see what was agreed, what they are asking for now and why the estimate moved. In practice, that is worth more than a “perfect” original specification.

Two ways an estimate moves, and why the baseline matters in both

What happens if you skip discovery?

Skipping Discovery does not eliminate the work it covers. It means that investigating the project starts at the same time as development.

Imagine a developer joins a project with this brief: “We need a system brokers can use to manage deals and send emails to lenders.” The developer can still start: configure the environment, request access, initialise repositories, set up infrastructure. Meanwhile, the BA/PM is still trying to find out what the product actually does. What exactly is a deal? Who creates it? Who can edit it? Which lenders receive which information? What goes into the email? What roles exist? Is there an admin interface? What happens after a deal changes?

The BA/PM can prepare assumptions and bring them to the client for confirmation to keep the project moving, and that approach can work. But the start is rushed and somewhat chaotic: the analysis happens in fragments, under pressure not to block the developers, and that raises the chance of missing something the team will have to come back to and rework later. Requirements analysis and development are now coupled together: there is no complete starting structure, and a decision made in one area can affect work already underway elsewhere.

With Discovery, the developer enters the project differently. Instead of a sentence describing the product, they receive a structured map of it — modules, flows, use cases and the estimates attached to them. They will still ask product questions. But they are starting from something substantially more useful than an idea.

The same brief, two very different starting points

AI has changed what clients bring into Discovery

Clients increasingly arrive with AI-generated product specifications, and this can help. A client who once would have brought half a page of notes may now bring a structured document describing features, flows and possible technical decisions — sometimes visibly refined over several iterations, with real effort invested in the idea.

That is useful input. But a well-structured document is not the same as a realistic scope.

AI tends to sell clients a lot of functionality. It describes an ambitious platform as if all its components naturally fit together, underestimates technically difficult features because they sound simple at a high level, and produces development estimates without enough project-specific information to make them meaningful. At the extreme, it will tell somebody they can build their own Facebook in two months. What usually lands on our desk is a large body of general information that takes several iterations to reduce to its essence: the document looks coherent; the assumptions underneath it are not.

This gives Discovery a new role. Previously, a BA spent much of the time helping a client structure an unstructured idea. Now the client may already arrive with structure, and the job is partly to determine which parts of it survive contact with reality.

AI can accelerate the beginning of Discovery. It does not replace it — and in some cases, it makes the validation part more important than before.

So what do $800 and 1–2 weeks actually buy you?

Not certainty. Not perfect estimates. Not an architecture carved in stone. And definitely not a product.

What they buy is a much better starting position. Instead of moving directly from “I have an idea” to “developers are writing code,” Discovery creates an intermediate stage where the idea is challenged, decomposed, clarified, prioritised and estimated.

You end up with a structured scope instead of scattered expectations. You have a baseline when the scope changes, and something concrete to discuss when an estimate changes. Developers have context before implementation begins. And, increasingly, you have a way to tell features that make sense for the actual product apart from features that simply sounded convincing when an AI generated them.

Whoever runs your Discovery — us or another team — the output should pass a few simple checks. The feature list is more specific than the pitch you walked in with. The risks and open questions are named, not summarised as “software projects carry risk.” The estimate comes with its reasoning. And the document would still be useful if you took it to a different team tomorrow.

The real value of Discovery is not that it predicts everything that will happen during development. It is that when development starts, everyone is working from the same map.

If you have an idea and are not sure how much of it is buildable — or how much of it is real — a short Discovery is where we would suggest starting.