What Should a Technical Discovery Actually Produce?
Discovery should hand you four things you keep whatever happens next: a decision list, a risk register, an architecture sketch, and an estimate with its assumptions. A proposal is not one of them.
On This Page
Two suppliers quote for the same build. One sends a proposal in four days. The other proposes a paid discovery of two or three weeks, ending in four documents and a number. The first quote is cheaper today. The question worth asking is which one leaves you holding something you can still use if you hire neither of them.
That is the test we would apply to any discovery: what do you still own if the project never happens? If the answer is “a proposal”, discovery was a sales process with a deliverable stapled to the end of it. If the answer is “a decision list, a risk register, an architecture sketch and an estimate with its assumptions written down”, it was discovery.
Those four technical discovery deliverables are the whole of it. Everything else the exercise produces, the workshop notes, the personas, the slide with a roadmap on it, is packaging. This piece describes what each artefact contains, how to tell a real one from a decorated one, and why the estimate is the least valuable of the four. Our own approach runs this sequence for the same reason: the artefacts are what survive contact with the project.
What a technical discovery is for
Discovery exists to convert unknowns into either decisions or priced risks. That is the entire job. Before it, you have a wish and a budget. After it, you should have a list of things that are settled, a list of things that are not and what each one might cost you, a picture of how the parts fit together, and a number whose arithmetic is visible.
Which means discovery is not requirements gathering. Requirements describe what you want. Discovery describes what will happen when somebody tries to build that here, on this stack, against this data, inside this organisation, under these constraints. The two get conflated constantly, and the difference shows up in month three, when a requirement meets a system nobody looked inside.
| Artefact | The question it settles | How you know it is real | Value if the project never runs |
|---|---|---|---|
| Decision list | What has been chosen, and what was rejected | Every entry names the option not taken | High: the reasoning outlives the supplier |
| Risk register | What could still go wrong, and what it would cost | Risks carry owners, triggers and a response | High: the same risks meet the next team |
| Architecture sketch | How the parts fit, and where the boundaries sit | It names systems you already own | Medium: it survives a change of builder |
| Estimate with assumptions | What it costs, and under which conditions | Each number traces to a named assumption | Medium: assumptions age faster than decisions |
| Proposal | Whether to hire this particular supplier | It is about them, not about your system | None |
The last row is the point of the table. A proposal is a legitimate document and every supplier should write one. It is simply not a discovery output. Our parent company has written about judging an agency without asking for spec work, and a paid discovery is the honest version of that idea: you buy a small piece of real work, then judge the work rather than the pitch.
Artefact one: the decision list
The most valuable document to come out of discovery is a list of decisions with reasons attached. Not preferences. Decisions: this rather than that, because of this constraint, and here is the consequence we accept in exchange.
A good list is short and slightly uncomfortable to read. It contains the choices somebody will want to reopen in month four, which is exactly why they are written down while everyone still remembers the reasoning. Rendering model, hosting, content storage, authentication, the boundary with systems you already run, and the choice of stack itself, which ought to read like a deliberate preference for boring technology rather than a preference for whatever the team last enjoyed using.
What an entry holds
- The decision, in one sentence. Written so that somebody joining next year understands it without needing the meeting it came from.
- The alternatives considered, by name. An entry with no rejected option was not a decision. It was a default that nobody examined.
- The constraint that settled it. A team skill, a data residency rule, an existing contract, a launch date, an accessibility target.
- The consequence you accept. Every choice buys something and pays for it somewhere else. Write down where.
- A date and a person. Decisions expire as conditions change, and one with no date cannot be reviewed sensibly.
Some entries are genuinely technical and belong in the sketch as well as the list. Whether the site is static, server-rendered or client-side has consequences for caching, personalisation, hosting cost and how quickly a visitor sees something useful. Other entries are commercial decisions in technical clothing, and the clearest of those is build or buy, which discovery should answer with evidence rather than with instinct.
Artefact two: the risk register
The risk register in a typical discovery report is three bullet points about scope creep and stakeholder availability. That is not a register. That is throat-clearing in a table.
A real one names risks specific to your build and prices them. The legacy system whose API has no documentation and exactly one person who understands it. The data migration where nobody has yet opened the export to look inside. The payment vendor whose sandbox behaves differently from production. The content that does not exist yet and has no author assigned to it. Each of those carries a trigger, an owner, a response and a rough cost if it lands.
An unknown is not a risk until you price it
The discipline is to convert every unknown into one of three things: a decision you can take now, a spike you can run before the build starts, or a risk carried into the estimate with a named cost. Anything still sitting as an unknown when discovery ends is a bill you have agreed to receive later without knowing its size. Say that sentence out loud in the review meeting. It changes the conversation quickly.
Some risks are contractual rather than technical and belong in the same register. If the build will process personal data through a third party, the terms you sign are part of the design, which makes what a data processing agreement should say a discovery question rather than a legal afterthought discovered the week before launch. The same is true of anything carrying a renewal date, a rate limit or a licence.
The most commonly unpriced risk is that the client cannot supply what the build needs: content, approvals, access, test data, a decision-maker who is reachable in August. Put it in the register with an owner on your side. A supplier who leaves it out is either being polite or planning to bill you for the delay it causes.
Artefact three: the architecture sketch
A sketch, not a specification. One page, or a small handful, showing the systems involved, what talks to what, where data comes to rest, and where the boundaries are drawn. It should be legible to a technical person in about a minute and explainable to a non-technical one in about five.
The test for whether it is real: does it name systems you already own? A sketch with a generic box labelled “CRM” was drawn from a template. A sketch naming your actual CRM, your actual payment provider, the spreadsheet three people quietly depend on and the reporting tool nobody will let you retire, was drawn from your organisation.
What the sketch must name
Four things, at minimum. Where the source of truth for each kind of data lives, because two sources of truth is the most expensive defect this document can contain. What happens when each external dependency is unavailable. Which parts are expected to change often and which are expected to sit still for years. And what is deliberately out of scope, drawn as a boundary on the page rather than omitted from it, so the exclusion reads as a choice instead of an oversight.
The sketch is also where standing cost becomes visible. Every box is something to run, patch, monitor and eventually replace, which is the argument in the standing cost of every feature you ship. Discovery is the cheapest moment there will ever be to delete a box. Once the build starts, deleting one becomes a conversation about sunk cost and somebody’s feelings.
Artefact four: the estimate, and the assumptions under it
The estimate is the artefact everyone reads first and the one that ages worst. Treat it as an output of the other three rather than as the reason discovery happened.
A number with no assumptions under it is not an estimate. It is a bid. The assumptions carry the information: that design is supplied by an agreed date, that there is one language at launch, that legacy data arrives as structured records rather than as scanned documents, that no new integration is added mid-build, that content is written by the client and arrives in a shape the templates accept.
Every assumption should be falsifiable, and each one should say what happens to the number if it fails. Not “costs may increase”. Something closer to: if the export turns out to be unstructured, add a data cleaning workstream and re-plan the migration before the build continues. That sentence is worth more than the number it qualifies, because it tells you which parts of the plan are load-bearing and which are decoration.
Constraints belong here too, written as targets rather than intentions. An accessibility target such as WCAG 2.2 AA is a scope item with real cost, and treating it as a value rather than a line item means paying for it later as rework. A performance budget behaves the same way: agreeing which Core Web Vitals thresholds you intend to hold changes component choices, image handling and how much client-side code the design can afford to carry.
When discovery is a sales process wearing a deliverable
The tells are consistent enough to list.
- It is free. Nobody funds weeks of senior time for nothing. If it costs you nothing, its purpose is to win the work, and its conclusions will point at the work.
- The output is a deck. Slides present a conclusion. Artefacts get used afterwards. Ask for the artefacts and see what actually arrives.
- Every recommendation happens to be in-house. Occasionally that is simply true. Usually it is a tell worth naming in the review.
- Nothing was rejected. A discovery that considered no alternatives decided nothing; it documented an intention.
- You do not own the output. Read the contract. If the documents cannot be handed to a different supplier without permission, they were never yours.
The most honest thing a discovery can conclude is that the build should not happen in the form it was requested. Sometimes the real answer is smaller: an existing product configured properly, or one well-made presence instead of an application. If what somebody actually needs is a polished, mobile-first profile site, an assembled product like Nichevio puts that together out of structured widgets and there is no project left to run. A supplier capable of reaching that conclusion and saying it out loud is the one worth hiring for the next thing.
That is uncomfortable, because it cuts directly against the incentive, and it is the clearest signal you will get about who you are dealing with. Our parent company made the underlying point in what a company actually sells: the deliverable and the value are rarely the same object, and confusing them is expensive for both sides.
A discovery is worth exactly what it is worth on the day you decide not to proceed. Whatever you still hold at that point was the real work.
How to commission one
If you are about to buy a discovery, set it up like this.
- Write the outcome, not the feature list. “Customers can renew without emailing us” beats “build a renewals portal”, because the second is already a solution and it forecloses the interesting options.
- Name the four artefacts in the statement of work. Decision list, risk register, architecture sketch, estimate with assumptions. Written into the deliverables clause, not implied by the conversation.
- Agree ownership in writing. You own the artefacts unconditionally, whether or not you proceed, and whether or not you proceed with the same supplier.
- Give access, not just meetings. Read access to the systems, a sample of the real data, and the person who knows the legacy quirks. Discovery without access is guesswork on a schedule.
- Time-box it hard. Two or three weeks concentrates the mind. A discovery that runs for months has become a project without an estimate.
- Book the review as a working session. Not a presentation. Go through the risk register line by line and argue about the assumptions. That meeting is where discovery pays for itself.
Where we would start
If a discovery report is already on your desk, do not read the estimate first. Read the assumptions, then the risks, then the decisions, and only then the number. If the assumptions are thin, the number is decoration. If the risks are generic, nobody looked at your system. If the decisions carry no rejected alternatives, nothing was decided and the choices will be made during the build by whoever happens to be typing that week.
If you are commissioning one for the first time, keep the scope narrow enough that the artefacts can be specific. A discovery covering one workflow end to end is worth more than one covering an entire platform at the altitude of a diagram. That holds as much for a new application as it does for improving something that already runs, where the risk register usually matters more than the sketch does.
The honest limitation: discovery does not remove uncertainty, and any supplier claiming it does is selling something else. What it does is move uncertainty from the middle of the build, where changing your mind is expensive, to the start, where it is cheap. Some risks stay open on purpose, because closing them would cost more than carrying them. Write those down as carried risks and carry them deliberately rather than by accident.
One last rule of thumb. If discovery ends and nobody on your side has changed their mind about anything, it did not work. The point was never to have your plan confirmed; it was to find out which parts of the plan were assumptions all along. If you are weighing a discovery proposal and want a second opinion on what it promises to hand over, send us the scope and we will tell you what is missing from the deliverables clause.
Common questions.
What is a technical discovery phase?
A technical discovery is a short, paid piece of investigation run before a build is committed. It examines the systems, data, constraints and integrations involved, then converts unknowns into decisions or priced risks. It differs from requirements gathering, which records what someone wants. Discovery records what will happen when that is built in a particular environment, with particular data and particular people.
How long should a technical discovery take?
Two or three weeks suits most single-product or single-workflow builds, and the time-box matters more than the exact length. A tight window forces the team to prioritise the unknowns that carry cost rather than documenting everything. If a discovery runs for months, it has quietly become a project without an estimate, and its artefacts will be out of date before the build even starts.
Should a discovery phase be paid?
Yes, and the fact that it is paid is what makes its conclusions trustworthy. Nobody funds weeks of senior engineering time for free, so an unpaid discovery is a sales activity whose findings will point toward the work being sold. Paying for it also gives you a contractual basis to own the artefacts outright and take them to a different supplier if you choose to.
What is the difference between discovery and requirements gathering?
Requirements gathering captures what stakeholders want the system to do. Discovery investigates what building that will actually involve: which systems hold the data, what the integrations really return, which constraints are fixed, and what could go wrong. Requirements produce a wish list. Discovery produces decisions, priced risks, an architecture sketch and an estimate whose assumptions are visible and can be challenged.
Who should be involved in a technical discovery?
On the supplier side, whoever will actually build the thing, rather than a separate pre-sales team who hands it over later. On the client side, a decision-maker with authority, the person who understands the legacy systems, and whoever owns the data. Access matters more than attendance: read access to systems and a sample of real data improves the output far more than another workshop does.
Can you skip discovery on a small project?
Sometimes, when the scope is genuinely small, the systems involved are ones you already understand, and no integration or data migration is in play. In that case the artefacts collapse into a page or two, which is fine. Skip it at your own risk when legacy data is involved, when a third-party system sits in the critical path, or when nobody currently employed can explain how the existing system works.
Facing this in your
own business?
Tell us where you’re headed — we’ll map the shortest honest route.