Discovery is the part of a software project most often paid for and least often received. It is easy to run workshops, produce a slide deck and call the phase complete, and the difference between that and real discovery only becomes visible in month three, when the requirements start moving.
Judge discovery by its documents. There are five, they are specific, and you should be able to hand them to a development firm that has never met you and get a comparable quote back.
The scope, with an exclusion list
The first document says what will be built, in what order, and explicitly what will not be built.
The exclusion list carries most of the value. Inclusions are agreeable and constrain nothing, since everybody is in favour of the features they want. Exclusions force the arguments to happen while they are still free, and they are the document you return to when someone asks in week three why the reporting dashboard is not in the build.
An exclusion list has to be specific to be useful. Naming a feature and giving the reason it waits is real. Excluding "anything not described above" restates the problem rather than solving it.
The data model
The second document draws the things your business deals in and how they relate. What a customer is, what an order is, what happens to a record when someone cancels, which of these can exist without the others.
This is the document that predicts whether a project will go well. Cost and risk in custom software live in the relationships between entities and in the states they can occupy, not in the number of screens. If nobody can draw your model after a week of conversations, the complexity has not been understood, and it will be discovered later while your budget is being spent.
You do not need to read it as an engineer. Ask whoever wrote it to walk you through it in business terms, and check whether the awkward cases you know about are represented. The ones that are missing are the ones that will hurt.
The architecture decisions that are expensive to reverse
The third document is short. It names the three or four choices that would be costly to change later, and why each was made.
Where the data lives. Which system is the source of truth when two disagree. How identity and permissions work. Which external systems have to stay in step.
Most architecture documents fail by describing everything at equal weight, which hides the decisions that matter inside a description of the ones that do not. The useful version is a page or two, and its purpose is that when one of those decisions turns out wrong, the reasoning is visible and the cost of changing it can be judged.
The assumptions and risks
The fourth document lists what has been assumed and what could go wrong.
Every estimate rests on assumptions, and an estimate that does not state them has either hidden them or made them unconsciously. The assumptions are exactly where the later disagreements come from: that the existing API can do what its documentation says, that the historical data is consistent enough to migrate, that the team on your side will be available for review.
Ask what happens if each assumption is false. That question converts a document into a plan.
The priced plan
The fifth document is the statement of work: the phases, what each contains, what each costs, and how long each takes.
Phased pricing matters more than the total. It keeps every individual commitment small, which is what the Standish Group's CHAOS research suggests you want, since small projects succeeded around 90 percent of the time against under 10 percent for large ones. It also gives both sides a natural point to change direction when reality differs from the plan.
Fixing the scope before the price, in that order, is the part that makes the number mean anything. A price attached to a description nobody has examined is a guess with a decimal point.
What discovery should cost, and why it should not be free
Discovery is real work by senior people, and free discovery is a sales activity. That is not a criticism of firms that offer it, just a description of what it is: unpaid pre-sales effort produces a document shaped to win the work, because that is what it has to do to pay for itself.
Ours starts at $3,000 and runs five to ten days, and the fee is credited toward the build if you go ahead. That structure keeps the incentive on producing a scope that is actually right rather than one that is attractive.
Priced against the build it protects, discovery is cheap. A poorly scoped $18,000 project can easily lose more than $3,000 to rework in its first month.
How to tell discovery did not happen
The estimate is broken down by screen. Cost lives in roles, integrations and data migration. A price list of screens means nobody examined the parts that carry risk.
Nobody asked to see your data. Discovery that never touched a real record has been conducted entirely on descriptions, and descriptions of data are reliably more orderly than the data.
There is no exclusion list. Every project has a boundary. If nobody drew it, you will find out where it is during a disagreement.
The output is a deck. Slides are for presenting conclusions. The artifacts above are what a developer works from, and a deck is not a substitute for any of them.
Nothing was ruled out. Real discovery kills at least one thing you walked in wanting. A process that validates every prior belief was a sales conversation with a longer timeline.
Frequently asked questions
How long should a discovery phase take?
Ours runs five to ten days. Longer usually means the scope has not been cut, or that discovery has become a project of its own. Anything under a few days rarely touches real data or real users.
Who should be involved from our side?
The people who do the work the software will change, not only the people who commissioned it. The most valuable material in discovery is the difference between how a process is described and how it actually runs, and only the second group can tell you that.
Can we do discovery ourselves?
You can do a large part of it. Writing down the workflow as it actually happens, listing the systems involved and collecting real examples of the awkward cases is genuinely useful and reduces what you pay for. The parts that benefit from outside experience are the data model and the architecture decisions.
Should the firm that does discovery also build?
Not necessarily, and keeping it separate is a reasonable way to get an unbiased scope. The test is whether the discovery documents are good enough to hand to someone else. If they are not, the discovery was incomplete regardless of who does the build.
What if discovery says the project should not happen?
That is a good outcome and worth what you paid. Finding out during a five to ten day exercise that the idea does not hold up is considerably cheaper than finding out during a build.
Where to start
If you are about to commission a build, the order that protects the money is scope first, price second. Our audit produces the five documents above, starting at $3,000 and credited toward the build.