A discovery phase is a short, paid piece of work before a build, in which somebody finds out what the project actually is. It typically costs five to fifteen per cent of the build and routinely saves more than that.
Businesses resist it because it feels like paying to be told what they already know. What it actually does is find the things they did not.
What gets discovered
How the work is really done
Every business has a documented process and an actual process, and they differ. The actual one includes the customer who is invoiced differently, the check somebody does in their head, and the spreadsheet that reconciles two systems every Friday.
Those exceptions are not edge cases to be tidied away. They usually exist for good reasons, and a system that ignores them will be worked around from the first week.
Finding them requires sitting with the people who do the job, not interviewing the person who manages them.
What state the data is in
This is where projects most often go over. Everyone assumes their data is reasonable. It is usually not.
Duplicate customers under three spellings. Dates stored as text. A notes field that has been used for six different purposes over eight years. Required information that is simply missing for records before 2019.
Discovering this before the build means it is planned for. Discovering it during means the project stops while somebody cleans several thousand records — a pattern covered in migrating without losing history.
What the other systems will actually allow
"It integrates with our accounts package" is a hope until somebody has read the documentation and tested it. Discovery is where you find out that the API is read-only, or does not expose the custom field the whole process depends on.
Who has to agree
Software projects fail on organisational grounds as often as technical ones. Discovery should establish who decides, who must be consulted, and whose working day changes. The last group is the one that determines whether the system is adopted.
What a discovery should produce
Not a slide deck. Documents you could hand to a different supplier and get a comparable quote.
A written description of the current process, including the exceptions, in language the business recognises.
A statement of what the system must do, separated into what is required for a first release and what can follow.
An assessment of the data, with the specific problems named and an estimate of the cleaning required.
An integration assessment, confirming what is possible with each connected system and what is not.
A risk list — the things that could make this cost more, stated plainly rather than buried.
A scoped plan with a cost range, broken into releases, with the first one small enough to be genuinely useful.
A recommendation, which may be to buy something instead, or to change a process rather than build software for it.
A discovery that concludes you should not build anything has saved you the entire build cost. That is a good outcome, not a failed one.
How it usually runs
Two to four weeks for a typical business system.
Days one to three: workshops with the people who do the work. Days four to six: examining the existing systems and a real sample of the data. The following week: integration checks, technical assessment, drafting. Final days: reviewing the draft with you and adjusting.
Your time commitment is real but modest — a few hours of workshops, access to systems, and one review session. The workshops need the people who actually do the job, which is the part businesses find hardest to arrange and which matters most.
Getting the commercial terms right
Fixed price, defined outputs. You should know exactly what you will receive.
You own the results. Including the right to take them to another supplier. A discovery you cannot use elsewhere is a sales exercise.
No obligation to proceed. The whole value is in being able to decide with information.
Sometimes credited against the build. Common and reasonable, though it should not come at the cost of the supplier's independence during the discovery itself.
The economics
The cost of a wrong assumption rises sharply with when it is found. A misunderstanding caught in discovery is a conversation. The same misunderstanding caught during the build is rework. Caught after launch, it is rework plus a system people have lost confidence in.
Projects that skip discovery do not avoid it — they perform it during the build, at full development rates, while the schedule slips.
When it is not needed
For small, well-understood work — a brochure website, a single integration between two well-documented products, a change to an existing system — a proper scoping conversation is enough.
Discovery earns its place when the process is unusual, when data must move, when several systems are involved, or when nobody can state the requirements confidently in one meeting.
Our consultancy team runs fixed-price discoveries for UK businesses, with the outputs yours to take anywhere. Start a conversation, and read build versus buy if you have not yet ruled out an existing product.
