Insights · 12 min read
What the discovery phase of a software project covers, what it produces, what it costs, and how to tell a real one from a formality before you commit.
By GGP Editorial
Most software projects do not go wrong in the code. They go wrong in the weeks before the code, when the idea in one person's head turns into a scope, a price, and a plan that three different people read three different ways. That translation work has a name. It is called the discovery phase, and it is the cheapest insurance you will ever buy against building the wrong thing.
I write this from the vendor side. GlobeSoft is a software company founded in 2018 with 40-plus engineers and more than 300 delivered projects. We run discovery on nearly every build we take on. This article explains what the phase actually is, what it produces, what it costs, and how to tell whether the one you are being offered is real or a formality.
Discovery is a short stretch of work at the start of a project. The goal is not to ship anything. The goal is to agree on what will be built, what it will cost, how long it will take, and what "done" means.
It is not a sales call. It is not a free consultation that turns into a quote. It is a scoped piece of work with a defined output, usually paid for and usually time-boxed to a few weeks. Some vendors fold it into the build. Others charge for it on its own. Either way, the work happens. If a vendor says they will skip it and jump straight to building, treat that the way you would treat a builder who wants to pour a foundation before looking at the soil.
Discovery ends in a document and a number. It does not end in software. That distinction matters, because the whole point is to spend a little now so you do not spend a lot later.
A good discovery phase answers a short list of questions. If you strip away the process language, this is all of it.
What is the product supposed to do, and what business problem does it solve? Most founders can answer this out loud. Writing it down, with the edge cases, is harder, and it surfaces disagreements that would otherwise show up mid-build as change requests.
Who are the users, and what do their actual workflows look like? Software built around a fictional user wastes money. Discovery interviews the people who will really use it, or at least the people who know those users best. Not the manager, the person who does the job.
What are the must-haves, and what can wait? This is the scope conversation. Version one of nearly every product is a third of the original wish list, once someone forces the trade-offs into the open.
What does the technical shape look like? Architecture, the technology stack, where the data lives, how it moves, what it connects to. This is where hidden costs surface: a third-party API you assumed was cheap, a legacy system with no clean interface, a data migration nobody budgeted for.
What could go wrong? A short risk list with mitigations. Compliance for a regulated industry, scale for a consumer product, security for anything holding payments or personal data.
What does it cost and how long will it take? The estimate and the plan. This is the output everyone waits for, but it is only as good as the answers that come before it.
Here is how those pieces line up against the questions they answer.
| Discovery deliverable | The question it answers |
|---|---|
| Product goals and success metrics | What problem does this solve, and how will we know it worked? |
| User profiles and workflows | Who uses it, and what do they actually do? |
| Prioritized requirements | What is in version one, and what waits? |
| Technical architecture and stack | What will it be built on, and what does it connect to? |
| Integration and data mapping | What systems and data does it have to work with? |
| Risk and compliance notes | What could break, and what rules apply? |
| Estimate and timeline | What will it cost, and how long will it take? |
The value of discovery is what it stops you from doing: building a product nobody wanted, or building the right product the wrong way.
I have watched the alternative play out. A client has a rough idea and a budget, skips discovery, and signs a fixed-price contract for a vague scope. Six weeks in, the team is building the wrong thing and both sides are arguing about whether a feature was "in scope." The project stalls, the relationship sours, and everyone pays for the gap between what the client imagined and what the vendor understood. Discovery closes that gap before it costs real money.
It also gives you something you can take to other vendors. A discovery document and an estimate from one shop is a real artifact you can use to sanity-check a second quote. That alone can be worth the fee, which is why we covered why custom software quotes vary so much in a separate piece.
I will not hand you a fake number here, because the range is too wide to be useful and anyone who quotes one without seeing your project is guessing. What I can tell you is how discovery is usually priced and what drives it.
Some vendors absorb the cost. If the project is likely to proceed, discovery gets folded into the build and you pay nothing separately. Others charge a fixed fee for a defined scope, which is the cleanest arrangement: you know the price and the deliverable before you start. A few run it on time and materials, which only makes sense for genuinely open-ended problems.
As a share of the project, discovery is small. On a mid-size custom build it is commonly in the low single digits of the total budget. On a small project it might be a flat workshop fee. The important rule is the same as anywhere else: get a fixed price for a defined scope, and make sure you can walk away with the output if you decide not to continue. The document is yours.
If you are still working out what the whole build should cost, how to estimate a custom software project walks through the logic that number depends on.
For most products, discovery runs one to four weeks. A simple internal tool or a small MVP might take a week. A complex platform with multiple integrations, a data migration, or a regulated domain can take a month. If someone tells you discovery takes three months, that is not discovery. That is a project wearing a disguise.
The duration depends on how much is already known. If you show up with a written product spec and a clear list of integrations, discovery is mostly confirmation and costing, and it is fast. If you show up with "I want an app like X," expect it to take longer, because the discovery is doing the thinking that normally happens before a project starts. The output quality does not change. The input does.
The more you prepare, the less discovery costs and the better the estimate. Bring three things.
A one-page problem statement. What is broken or missing today, for whom, and what would be different if the software worked.
The real users, or access to them. At least one person who actually does the job the software will touch.
Every system the software has to talk to. The CRM, the payment provider, the warehouse system, the spreadsheet that quietly runs the company. Naming these in week one saves a change request in month two.
If this is your first time doing any of it, we wrote a guide for exactly that situation: software development for non-technical founders.
Honesty cuts both ways here. Not every project needs a full discovery phase, and a vendor who insists on one regardless is padding the invoice.
Skip it when the product is small and you have already done the thinking. If you have a written spec, a clear user, a known data source, and a rough budget, a full discovery phase is ceremony. A short scoping call and a fixed estimate is enough.
Skip it when the problem is well understood and the risk is low. A simple internal tool with one user group and no integrations does not need a month of discovery. A multi-market brokerage platform with real-time data and compliance rules does, and that is exactly the kind of project where GlobeSoft has spent years, from trading systems spanning Hong Kong, US, and A-share markets to a self-ordering and POS system for restaurants.
The test is simple: if the cost of building the wrong thing is small, spend less on deciding. If it is large, spend more. Discovery is a hedge, and you buy it in proportion to what a miss would cost you.
A real discovery phase ends with decisions. A fake one ends with meetings.
A good one gives you a document you can act on: requirements, priorities, architecture, risks, estimate, plan. It names the things you are not building in version one, which is the uncomfortable part that actually saves money. It hands you a number with the assumptions behind it, so you can see what changes the price. It tells you something you did not know about your own idea, because if the discovery produced no surprises, it probably did not dig.
A bad one looks different. It is mostly discovery of your budget, not your problem. It produces a glossy deck with market statistics and no specifics about your data or your users. It ends with a vague estimate and a request for a deposit "to continue the discussion." If you see those three together, you are not in a discovery phase. You are in a sales funnel with extra steps.
The same instinct applies to picking the vendor in the first place. How to hire a software development company covers what to ask before you get this far.
Discovery ends, and one of three things happens.
You build. You sign the contract, the estimate becomes the budget, and development starts. Because the scope was agreed up front, the first sprint actually builds something instead of reopening every decision. We wrote about the two main ways to pay for that work in fixed price vs time and materials.
You narrow the scope. The estimate comes back higher than your budget, and you use the prioritized list to cut the tail before writing a single line of code. This is the cheapest possible moment to shrink a project.
You walk away. The discovery showed the idea is not viable, or the numbers do not work, or you do not trust the vendor. That is a good outcome too. A small fee to learn you should not spend a few hundred thousand is a bargain.
There is one more path worth naming: you take the discovery document to a second vendor for a competing quote. The document is yours. That freedom is part of what you are paying for, and it is why you should never sign anything that keeps the output hostage.
If the discovery shows your idea is too big for a first release, how much MVP development costs explains how to cut it down to something you can actually ship.
What is the difference between discovery and scoping?
Scoping is one slice of discovery. Scoping defines what is in and out of the build. Discovery includes scoping but also the architecture, integrations, risks, and estimate that turn a scope into a plan and a price.
Do I have to pay for a discovery phase?
Not always. Many vendors fold it into the build. If it is charged separately, make sure you get a fixed price, a defined deliverable, and ownership of the output whether or not you proceed.
How much does a discovery phase cost?
It varies too widely for a useful single number. It is normally a small share of the total project, often absorbed into the build, and priced as a fixed fee when it is charged separately. Ask for the price of the discovery itself before you commit to anything.
How long does discovery take?
One to four weeks for most products. A week for a small, well-defined build; longer for a complex platform with integrations, data migration, or regulation.
What should I do before starting discovery?
Write a one-page problem statement, bring the real users into the room, and list every system the software has to connect to. The more you prepare, the cheaper and sharper the phase is.
Who runs the discovery phase?
A small team, usually a product or business analyst plus a senior engineer, sometimes an architect for complex systems. The same people should carry into the build, so the thinking is not lost in a handoff.
Discovery is the part of a software project where you decide what you are actually building, before the meter starts running on building it. It ends in a document, a number, and a plan, and it should surprise you at least once. If the vendor wants to skip it, or wants to charge you to keep discussing, find a different vendor.
If you have a project in mind and want to run a proper discovery phase, talk to us about your project. GlobeSoft can take you from a one-page idea to an agreed scope, architecture, and budget, in English or Portuguese, across time zones.
Tell us what you are building and where you are today. We typically reply within 24 hours.
