What a two-week discovery has to deliver to be worth paying for
A discovery that produces a proposal is a sales process. Five artifacts that make it an engineering deliverable you own and can hand to any vendor.
Paid discovery has a bad reputation, and often earns it. Two weeks go by, a slide deck arrives, and the deck is a proposal for the project the vendor wanted to sell in the first place. You paid to be sold to.
A discovery is worth paying for when it produces artifacts you own, that are useful even if you never hire the vendor who wrote them, and that would let a different team start on Monday.
The test
Before it starts, agree on this criterion:
If we stop here and hand this to another firm, can they begin work without repeating the discovery?
Everything below follows from that. It also makes the engagement honest: a vendor who accepts this criterion is betting that being useful wins the work, which is the incentive you want.
Five artifacts
| Artifact | What it contains | Why it survives the engagement |
|---|---|---|
| System map | What exists today: systems, data flows, integrations, owners | Nobody has this written down, and everybody needs it |
| Constraint list | What cannot change, and why: contracts, compliance, immovable systems | Constraints found late are what break plans |
| Risk register | What is unknown, ranked, with the cost of finding out | Names the things that will blow up the estimate |
| Sequenced plan | What to build first, second, third, and what each unlocks | A plan with an order is a plan you can stop midway |
| Decision record | Choices made during discovery, with alternatives rejected and why | Prevents relitigating the same debate in month four |
The risk register is the one most often missing and the one that pays for the engagement. A discovery that reports only what it found is describing the easy half. The valuable output is the ranked list of what nobody could determine in two weeks, with an estimate of what each unknown could cost.
What has to happen during the two weeks
The artifacts only come out if the process actually goes looking.
Read the code, not just the documentation. Documentation describes intent. Code describes behavior. Where they disagree, the code is what runs in production.
Look at the real data. Profile it. Count the nulls, the duplicates, the values that violate constraints the application supposedly enforces. Data migration estimates that were made without looking at data are guesses, and it is a leading term in what custom software actually costs.
Talk to the people who operate it. Not only the people who commission it. The person who runs the nightly job knows which failure is normal and which is not, and that knowledge is in nobody's document.
Try the risky thing. If the whole plan depends on an undocumented API responding in a certain way, spend a day proving it. A spike that fails in week one is the cheapest failure available.
What a discovery cannot do
Setting the expectation honestly matters as much as the work.
It cannot produce a fixed price for a system with real unknowns. It can produce a price for the first phase and a range for the rest, with the assumptions written down. Anyone who converts two weeks of looking into a firm number for a year of work is pricing risk, and you are paying for it.
It cannot resolve organizational disagreement. If two departments want different things, discovery will surface that clearly and will not settle it. That is a decision someone with authority has to make, and the discovery's job is to make the trade explicit.
It cannot substitute for building. Some questions are only answerable by writing code. The right output is a named spike in phase one, not a longer discovery.
After it ends
The plan should have a first phase you could execute with a different team, and a stopping point where you would still have something useful. If the sequence only produces value at the end, it is not a sequence, it is a single large bet with milestones drawn on it.
For a system that must keep running while it is replaced, that sequencing is a strangler-fig migration, and the discovery's job is to pick the first slice.
If you are running this as part of vendor selection, the discovery is also the evaluation: judge the artifacts on their merits, which is the approach in how to tell whether a vendor can actually build it.
This is how our engagements start. What we produce and how we handle access to your systems during it is in our security practices, and the shape of the work is under custom software development.