Discovery should be a small fixed-price project, not a free sales exercise

January 28, 2026 · 5 min read · HQT

The expensive decisions on a software project get made before anyone writes code. Requirements are drafted from an org chart instead of from the work. The integration that turns out to be the hard part appears as one bullet in an appendix. Discovery is where those questions are still cheap to ask. After the contract is signed, every remaining option costs more.

We run discovery as a real project, not a free assessment offered in hope of a larger award. Ours are two to four weeks, fixed price, with a named team and a defined set of deliverables the agency owns at the end.

Why we charge for it

Free discovery is not free. Work given away is recovered somewhere, usually in the implementation estimate. Unpaid discovery also carries a bias, because the firm doing it has an interest in concluding that a large custom build is required. A fixed fee makes it possible for us to write "you do not need new software here, you need a configuration change and a process decision" without that sentence costing us the work.

Two to four weeks is long enough to read the code, profile the data, and sit with the people who use the system every day, and short enough that the findings are still accurate when the solicitation gets written.

Price matters for procurement reasons too. Procurement codes generally set dollar thresholds below which a purchase can be made through small purchase or simplified procedures instead of a formal solicitation, and agencies spending federal award funds work under a parallel set of methods in the federal uniform guidance. Those figures are revised periodically and differ by state, agency, and funding source. Confirm the current rules with your purchasing office.

What the weeks contain

Access and interviews come first, with the people doing the work and not only their supervisors. We would rather watch a clerk process an application than run a requirements workshop, because a workshop describes the process as designed and the desk shows it as performed. In parallel we inventory: the application, its integrations, where it is hosted, who holds administrative credentials, and whether backup and recovery actually work as documented.

The middle stretch is technical and data assessment. We profile a copy of real data, because data quality is where schedules fail. Fields that are supposed to be structured often hold free text, and a count that two departments both report is often computed two different ways. Neither problem is visible in a schema diagram.

The last stretch is options and estimates, drafted, walked through with agency staff, then revised. A finding the agency has not argued with is not one they will defend in a budget meeting.

What we hand over

1. A current state description, including the behavior nobody documented
2. A prioritized problem list separating software problems from process problems
3. A data assessment covering quality, volume, and the cleanup a migration would require
4. An integration and interface inventory
5. Two or three implementation options with tradeoffs, cost ranges, and schedule shape
6. A recommended approach whose first phase delivers value on its own
7. Procurement material: a draft scope of work, deliverables with acceptance criteria, and evaluation criteria
8. A risk register with named owners

All of it in editable formats, with no restriction on reuse. The agency should be able to hand the package to any vendor, including vendors that are not us.

What fixed price forces on us

Hourly discovery rewards thoroughness past the point of usefulness. A fixed fee forces the scoping conversation to happen before the money moves: how many interviews, which systems are in scope, whether a prototype is included, and what is excluded. It also forces us to write down our assumptions, mainly environment access, a data extract, and an agency point of contact with time available. When an assumption fails, the schedule moves and the price does not.

Some engagements include a narrow prototype built against synthetic data, using reference builds we maintain internally. A screen a department head can click through settles arguments that a document cannot.

How discovery fails

• It produces an architecture document nobody can procure from. If a solicitation cannot be written out of the deliverables, it failed.
• Only management is interviewed, so the report describes the process as designed.
• It ends with one option, which is a proposal wearing a different label.
• It sits until the findings are stale. Write the solicitation while they are current.

How to buy it

Buy discovery as a standalone purchase with its own deliverables and acceptance criteria. Write ownership of the work product into the terms, including the editable source files. Require at least two options, one of which does less than you think you want.

Ask counsel early how your jurisdiction treats a firm that performs discovery and then bids the implementation. Procurement rules commonly address this, some by barring a vendor that helped write specifications from competing on the resulting award, others by requiring disclosure and a mitigation plan. Settle it before the discovery contract is signed, because the answer shapes how the deliverables should be written.

We run discovery knowing the conclusion may be that the build should be smaller than expected, or that it should go to someone else. That is what paying separately for the answer buys.