Paying for a Plan, Not a Pitch: What Two Weeks of Discovery Owes You

A paid discovery is worth the fee only if what it produces would still be useful to you after you fired the firm that wrote it. If the output is a proposal with nicer formatting, you have funded someone's sales process. The standard to hold it to is simple: a set of written documents, owned by you, that a different engineering team could pick up and start building from.

How discovery got its reputation

Many leaders have been through the bad version. A vendor proposes a short paid phase to "understand the business". There are a few workshops with sticky notes. Two weeks later a slide deck arrives, and its conclusion is that you should buy the project the vendor described in the first sales call, at about the price they mentioned then.

Nothing in the deck was false. It also contained nothing you could use without them. No one read your code, no one queried your data, and the only risks listed were generic ones such as "stakeholder alignment".

The good version exists and looks very different. The format of the engagement is the same in both. What changes is the acceptance criterion agreed at the start.

Agree on the handoff test before day one

Put one sentence into the statement of work:

At the end of this engagement, a competent team that has never spoken to the authors must be able to begin the first phase of work using only the delivered documents.

This sentence does a lot. It defines "done" in a way you can check. It rules out a slide deck as the deliverable. It forces the authors to write down what they learned instead of keeping it in their heads as a hold over you.

It also sets up the right incentive. A firm that accepts this condition is betting that being useful is the best way to win the build. A firm that resists it is telling you their plan depends on you needing them.

The five documents

Each of these should be a real document, with prose and diagrams, that you could open a year from now and still act on.

1. A map of what exists

Every system involved, what data each holds, how data moves between them, which integrations exist and how they work (API, file transfer, database link, a person retyping), and who owns each piece. Include the unofficial parts: the spreadsheet that finance reconciles by hand, the scheduled script on someone's desktop.

Almost no company has this written down in one place, and every later decision depends on it. This document stays useful even if no project follows.

2. A list of fixed constraints

Everything that cannot change, and the reason. Contract terms with customers or vendors. Compliance obligations. A system that must stay because another department depends on it. A budget cycle. A seasonal freeze when nothing may be deployed.

Constraints discovered in month five are what break plans. A constraint written down in week two is just a design input.

3. A ranked register of risks and unknowns

Of the five, this document gets left out more than any other, yet the fee is justified mainly by it. Reporting what was found is the easier half of discovery. The harder half is an honest list of what could not be determined in two weeks, ordered by potential impact, with a note on what it would take to find out.

Here is what useful entries look like, for a hypothetical project replacing an order system:

Each entry names something specific, says what depends on it and prices the investigation. Compare that with "integration complexity: medium".

4. A sequenced plan

What gets built first, second and third, why in that order, and what each step makes possible. Good sequencing puts the riskiest assumption and the earliest usable value near the front. Each phase should end at a point where you could stop and keep something that works.

The plan should come with an estimate that is honest about its precision: a firm figure or tight range for the first phase, wider ranges for later ones, and the assumptions behind each written next to the number.

5. A decision log

Every significant choice made during the two weeks: what was decided, which alternatives were considered and why they were set aside. "We recommend keeping the existing warehouse system and integrating with it, instead of replacing it, because..." is the kind of entry that saves you from reopening the same argument four months later with people who were not in the room.

What the two weeks should look like

Documents of that quality come out only if the team actually goes looking. This is a reasonable shape for the ten working days.

Days 1 and 2: access and orientation. Read-only access to repositories, databases and existing documentation should be arranged before the start date. The team meets the sponsor and learns what the business is trying to achieve and what would count as success.

Days 3 to 5: primary sources.

• Read the code. Documentation tells you what someone intended at the time of writing. The code tells you what happens today. When the two conflict, the code is the truth, because the code is what runs.
• Query the data. Count nulls in fields that are supposedly required. Count duplicates. Look for values that the application claims to prevent. A migration estimate produced without profiling the data is a guess.
• Interview operators, not only sponsors. The person who restarts the nightly job knows which error is routine and which one means trouble. The accounts clerk knows which report nobody trusts. That knowledge is in no document.

Days 5 to 7: test the riskiest assumption. Suppose everything downstream relies on one integration responding as expected: the team should prove that with real calls, which rarely takes more than a day or two. This technical spike is what separates discovery from a reading exercise. An assumption that fails in week one costs a day. The same failure in month three costs a redesign.

Days 8 and 9: synthesis. Draft the five documents, sequence the plan, build the estimate.

Day 10: review with you. The team walks you through the findings, you challenge them, and corrections are made before the final delivery.

What you have to bring

A discovery can fail on the client side too. Three things are needed from you.

1. Access, ready on day one. If credentials take a week to arrange, you have paid for half a discovery.
2. Time from the right people. A few hours each from the operators and system owners, scheduled in advance.
3. One person with authority. Someone who can answer "which of these two goals wins?" during the engagement, not after it.

What discovery cannot do

Being clear about the limits protects both sides.

A firm quote for the entire project is out of reach while real unknowns remain. The honest output is a committed figure for phase one, plus low and high bounds for everything after it, with assumptions stated. If someone turns ten days of investigation into a single firm figure for a year of work, they have added a risk premium to cover what they do not know, and you are paying that premium whether or not the risks occur.

It cannot settle a disagreement inside your company. If sales wants flexibility and finance wants control, a good discovery will lay out that conflict clearly, with the cost of each option. It will not resolve it. That takes a decision from someone with the authority to make it.

It cannot replace building. Some questions are answered only by writing the software and putting it in front of users. The right response is a named experiment in the first phase of the plan, not a longer discovery.

It cannot remove risk. Ten working days will get you a map of the system and an ordered list of what is uncertain. Making that uncertainty disappear takes far longer. If a discovery ends with complete confidence and no open questions, the team did not look hard enough. Treat an empty risk register as a warning sign.

How to judge what you received

When the documents arrive, run through these checks.

• Could another firm start phase one from this alone? Ask one of your own engineers to read it cold.
• Did you learn something about your own systems that nobody on your team knew?
• Does the risk register include items that are inconvenient for the authors, such as reasons the project might be smaller than proposed, or might not be worth doing?
• Was something actually tested, with results shown?
• Does every estimate have its assumptions beside it?
• Does the plan deliver something usable before the final phase? If value appears only at the very end, what you hold is a single all-or-nothing wager dressed up with checkpoints, not a sequence.
• Is at least one recommendation "do not build this part" or "buy this instead"?

After the two weeks

A good discovery leaves you with choices. You can proceed with the same firm, take the plan to others for competing quotes, hand it to your internal team or decide not to proceed at all. All four are legitimate outcomes, and the fourth can be the most valuable one.

If the project replaces a system that has to keep running during the transition, the plan should identify the first slice to carve off and route around the old system, in the style of a strangler fig migration, instead of proposing one cutover date.

If you are still choosing a vendor, the discovery is also the best evaluation tool you have. You get to see how a team thinks, on your own problem, for a small part of the total budget.

Would your last discovery pass the handoff test?

Trivo's Two-Week Discovery costs a fixed $7,500, credited in full toward the build if you continue with us. The written plan is yours either way: system map, constraints, ranked risks, sequenced plan and decision log, ready for any team to use.