What to Ask Before You Pay for a Discovery Sprint

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: A VP of Engineering or COO at a US enterprise (500–2,000 employees) who has been burned by a previous vendor that charged $25K–$50K for a discovery engagement and delivered a slide deck that locked them into that vendor's preferred architecture

The one test that matters: can the SOW, architecture decision records, and acceptance criteria your discovery sprint produces be handed verbatim to a competing vendor on day one of the build? If the answer is no — or if the vendor won't put that portability guarantee in writing before you sign — you're not paying for requirements. You're paying for a document that prices your switching cost. The questions below are designed to surface that answer before the invoice, not after.

This post assumes you've already been burned once. You know what a 60-slide deck full of vendor-flavored architecture diagrams looks like. You know the feeling of calling a second firm for a competitive bid and realizing the first vendor's "data model" is actually a schema for their proprietary platform. The goal here is to pressure-test the next engagement during the sales conversation — the one window where you still have leverage.

Why this matters more than the sticker price

A healthcare or FinTech discovery audit at the enterprise end runs roughly $30K–$60K over about six weeks under a project-based engagement, according to Cleveroad's 2026 IT consulting benchmark. That's not the number that should scare you. The number that should scare you is downstream: PMI's Pulse of the Profession found 37% of organizations cite inaccurate requirements as the primary reason for project failure, and 51% of project and program dollars are wasted on poor requirements management. IAG Consulting's benchmark puts the cost differential at $2.24 million more per strategic project for companies with poor requirements practices versus best-in-class.

Then there's the lock-in tax. A February 2026 Capgemini Engineering preprint quantified AI vendor switching costs at 2.3x to 5.7x the original implementation cost. If discovery hands you an architecture that only one vendor can execute, you've effectively prepaid the lock-in premium before writing a single line of code.

The questions below are grouped by stage: the sales call, the technical deep-dive, the security and legal review, and the pilot debrief. Use the ones that match where you are.

Stage 1: The sales call (questions 1–6)

1. "Will the SOW, data model, and architecture decision records be written in vendor-neutral form, and will you contractually permit us to issue them to a competing build vendor?"

Why it matters: This is the single most diagnostic question in the entire interview. Everything else is detail.

Good answer sounds like: "Yes, we write ADRs in the format Michael Nygard popularized — context, decision, consequences, alternatives considered. We'll include a clause in the discovery MSA that assigns IP to you and explicitly permits re-use with any vendor. We lose some deals this way, but it's how we price discovery honestly."

Red flag: "Our methodology is proprietary" or "The deliverables are optimized for our build process, but you can of course share them." The second half of that sentence is doing enormous work. Ask to see the clause in writing.

2. "Can we see three discovery deliverables from past engagements, with the client's name redacted?"

Why it matters: Discovery output quality is wildly variable and almost impossible to assess from a capabilities deck. A vendor who has done this well before can show you anonymized examples within 48 hours.

Good answer: You get three real documents — not slide decks, but the actual SOW, a data model diagram, and a risk register. The documents reference generic tech choices (Postgres, Kafka, React) more than branded ones.

Red flag: "Everything we produce is under NDA" (then they haven't negotiated reusable samples, which is itself a signal), or they send you a 40-slide "discovery output" that is 80% context and 20% recommendations — all of which point to one specific build approach.

3. "Who specifically will do the discovery work, and what percentage of their time is on this engagement?"

Why it matters: The classic bait-and-switch: senior architects in the sales call, junior analysts in the Zoom rooms.

Good answer: Named individuals, LinkedIn profiles, calendar commitment ("Priya is 60% on this for six weeks; here's what else she's doing"), and a clause allowing you to reject a substitution.

Red flag: "We'll assign the right people from our bench." Translation: whoever is free that Monday.

4. "What is explicitly out of scope for discovery, and what happens when we hit it?"

Why it matters: Scope creep in discovery is where the $35K engagement becomes $85K, and it's usually because the vendor deliberately scoped loosely.

Good answer: A written out-of-scope list — e.g., "We will not do penetration testing, we will not interview more than 12 stakeholders, we will not evaluate more than 3 build-vs-buy alternatives for any single component." Plus a change-order process with a cap.

Red flag: "We'll figure out scope as we go — discovery is inherently exploratory." This is true in spirit and dangerous in a contract.

5. "If we decide not to proceed to build with you, what do we owe at the end of discovery?"

Why it matters: Some vendors structure discovery as a loss leader with a termination fee or a "build credit" that evaporates if you choose someone else. That's a lock-in mechanism dressed as a discount.

Good answer: "Nothing beyond the discovery fee. The deliverables are yours. We'd obviously love to bid on the build, but there's no penalty if we don't win."

Red flag: Any "discovery credit applied to build" structure that's only redeemable with them, or exit fees tied to IP release.

6. "What does your discovery process say 'no' to? Walk me through a recommendation you made against building something."

Why it matters: A vendor who has never recommended "don't build this" is a vendor whose discovery is a sales qualification funnel.

Good answer: A specific story — "We told a logistics client to use an off-the-shelf TMS instead of building. We lost a $400K build engagement and got a $20K integration project instead."

Red flag: Hand-waving about "we always align to what's right for the client" with no example.

Stage 2: The technical deep-dive (questions 7–11)

7. "How will you document architecture decisions, and in what format will we receive them?"

Why it matters: ADRs are the portability unit of modern software architecture. A vendor who doesn't use them, or uses a proprietary equivalent, is building you a document only they can read.

Good answer: "Markdown ADRs in your Git repo, Nygard format. One per decision. We'll produce 15–30 of them during discovery, covering data store choice, auth strategy, deployment target, event bus, and so on."

Red flag: "We'll capture it all in our discovery deck" or "We use our internal architecture framework."

8. "How many build-vs-buy alternatives will you evaluate for each major component, and how will you document the trade-offs?"

Why it matters: Vendors who make money on build hours have a structural incentive to recommend building. The question forces them to show their work.

Good answer: "For each major component — identity, payments, search, notifications — we evaluate at least two SaaS options and one build option. The write-up includes total cost of ownership over three years, integration effort, and exit cost."

Red flag: Pure build recommendations with vague references to "flexibility" and "future-proofing."

9. "What's your approach to data modeling during discovery, and will the model be portable across database engines?"

Why it matters: A data model that assumes a specific vendor's platform (say, a managed graph DB only they operate) is a Trojan horse.

Good answer: "Logical model first — entities, relationships, cardinality — in a tool-agnostic format. Physical model recommendations come with at least two engine options and a migration path between them."

Red flag: Jumping straight to a physical schema in one specific technology without discussing the logical layer.

10. "How will you handle AI/ML components so we're not locked into one model provider?"

Why it matters: This is the 2026 version of the question. If discovery recommends an architecture tightly coupled to one foundation model API, you've baked in the 2.3x–5.7x switching cost documented by KongHQ citing CIO Dive and Capgemini.

Good answer: "Abstraction layer between application and model provider. Prompts and evals version-controlled separately. We'll recommend a primary and a fallback provider, and the architecture supports swapping either."

Red flag: Direct SDK calls to one provider throughout the proposed architecture, with no abstraction discussed.

11. "What's in the risk register, and who owns each risk after discovery closes?"

Why it matters: A risk register that lists only technical risks and omits commercial, regulatory, and organizational ones is incomplete. Ownership matters because unassigned risks are forgotten risks.

Good answer: A register with 20–40 items spanning technical, data, compliance, vendor, and change-management risks. Each has a probability, impact, mitigation, and a named owner on your side (not theirs).

Red flag: A one-page "risks and assumptions" slide with five bullets.

Stage 3: The security and legal review (questions 12–14)

12. "What's in your discovery MSA about IP assignment, and when does assignment take effect?"

Why it matters: "IP transfers on final payment" means the vendor owns your discovery output until the invoice clears, and some vendors use that window to pitch a build contract. Assignment should be on creation, not on payment.

Good answer: "Work-for-hire, IP assigned on creation, no license-back required." This is a legal review item — your counsel should read the actual clause, not take the sales team's summary.

Red flag: Perpetual licenses to the vendor to "use learnings" in other engagements, or IP transfer gated on "successful completion" (whose definition?).

13. "How do you handle access to our systems during discovery, and what's your data retention policy afterward?"

Why it matters: Discovery often requires read access to production data, logs, or user research. What happens to that data 90 days after the engagement ends?

Good answer: Named individuals with SSO access, access revoked on day one of close-out, written attestation of data destruction within 30 days, and a specific sub-processor list if any work is subcontracted.

Red flag: Shared logins, no destruction attestation, or vague references to "industry-standard practices."

14. "Will you sign a non-solicit covering our interviewees, and will you commit to not pitching other vendors in our stakeholder meetings?"

Why it matters: Discovery vendors sometimes use stakeholder interviews as business-development opportunities for their partner network. You're paying for their attention, not their rolodex.

Good answer: Both commitments in writing, with a defined duration (typically 12 months).

Stage 4: The pilot or close-out debrief (questions 15–17)

15. "If we take these deliverables to three competing build vendors, what would they each need to clarify before quoting?"

Why it matters: Ask this at the discovery close-out, before you accept the deliverables. If the honest answer is "a lot," the discovery isn't finished.

Good answer: A short list of 5–10 clarifications any vendor would need, plus an offer to answer them in writing on request.

Red flag: "They'd need to re-do most of this because every vendor approaches it differently." That's an admission that the discovery was vendor-specific.

16. "What acceptance criteria would you accept being measured against, and are those criteria in the deliverables package?"

Why it matters: Acceptance criteria written during discovery and handed to a different build vendor are the mechanism that prevents scope drift during build. If they're absent, the next vendor writes their own — and you lose the alignment you paid for.

Good answer: Testable, numbered acceptance criteria for each major capability, written in a format (Gherkin, user story + ACs, or similar) that any build team can execute against.

17. "If we hire you for the build, what in your discovery would you change knowing what you learned?"

Why it matters: Honest answer here reveals whether the vendor treats discovery as a living document or a frozen sales artifact.

Good answer: "Three or four things — we underestimated the data migration effort, we'd push harder on the auth decision, we'd add a spike on the integration with your ERP."

Red flag: "Nothing — the plan is solid."

What the cost and timeline model actually looks like

Discovery pricing is driven by four variables: number of stakeholder interviews, number of existing systems to inventory, regulatory scope (HIPAA, SOC 2, PCI, GDPR each add weeks), and whether a working prototype is part of the output. Cleveroad's benchmark puts a healthcare or FinTech discovery audit in the $30K–$60K range over about six weeks — illustrative of the shape, not a quote for your situation.

The variables that move it most: a discovery that must inventory 15+ existing systems and interview 25+ stakeholders across three business units will land at the top of that range or above. One that covers a single product line with a known tech stack lands at the bottom. A prototype adds two to four weeks. Compliance scoping (particularly for regulated data) adds a specialist and a week or two.

What you control: the number of stakeholders you expose, the clarity of the problem statement you walk in with, and whether you've done internal pre-work (a current-state architecture diagram, a shortlist of must-have integrations). What you don't control: the vendor's bench depth, their actual experience in your regulatory domain, and how much of the sprint is spent on their learning curve versus your problem.

To turn the range into a real quote: (1) write a one-page problem statement with the top three business outcomes, (2) list the systems that must be touched or integrated, (3) name your compliance regime. Then a vendor can scope honestly. The McKinsey data on requirements-driven failures (68% of software project failures trace to poor requirements) is why this up-front investment is defensible — but only if the output is portable.

How CodeNicely can help

We've run paid discovery sprints that ended with the client taking the SOW to another firm for the build. That's not a failure mode we flinch at — it's how we price discovery honestly. The GimBooks engagement is the one most relevant to a VP of Engineering who's been burned before: a YC-backed fintech where discovery produced a data model and ADRs that survived two subsequent architecture pivots because they weren't coupled to a specific platform. The acceptance criteria written in week five were still being used in sprint planning 18 months later.

For enterprises evaluating an AI-heavy build, our AI Studio treats model-provider abstraction as a day-one architectural requirement, not a retrofit — which is the only way to keep the switching cost numbers in the Capgemini preprint from showing up on your P&L in year three. US buyers can start on our US practice page; our full services catalog is on offerings.

What we're bad at: we won't win a bake-off on pure methodology theater. If a vendor is showing up with a 200-page discovery playbook and a certified framework name, we'll lose that comparison. We optimize for deliverables you can hand to someone else, which is a weaker sales motion and a stronger buyer outcome.

Frequently Asked Questions

How long should a paid discovery sprint take for an enterprise software project?

Four to eight weeks is the typical shape for an enterprise engagement, driven by the number of stakeholder interviews, systems to inventory, and regulatory scope. Healthcare and FinTech sit at the longer end because of compliance scoping. Anything under three weeks is usually too shallow to produce portable artifacts; anything over ten is usually scope creep. The specifics that would narrow this for you are the number of integrations, the number of business units involved, and whether a working prototype is part of the output — worth a scoping conversation.

What's the difference between a discovery sprint and a design sprint?

A design sprint (Google Ventures format) is five days, focused on validating a product concept with users through a prototype. A discovery sprint is weeks long and focused on producing build-ready engineering artifacts: SOW, data model, ADRs, risk register, acceptance criteria. Design sprints answer "should we build this?" Discovery sprints answer "what exactly are we building and how?" Enterprises usually need both, in that order.

Should the same vendor do discovery and build?

Not necessarily, and the fact that you can credibly separate them is the test of whether discovery was done honestly. If the deliverables are portable, you have optionality — you might choose the same vendor for continuity, or a different one for cost or specialization. If the deliverables aren't portable, the "choice" is theater. Keep the two contracts separate and don't sign the build until discovery is accepted.

What are the biggest red flags in a paid discovery proposal?

Proprietary deliverable formats, IP assignment gated on final payment or "successful completion," discovery credits only redeemable with the same vendor for build, vague scope with no out-of-scope list, and refusal to share anonymized samples. Any one of these in isolation is manageable; two or more together usually means the discovery is priced as a sales qualification tool, not as independent engineering work.

How do we evaluate discovery deliverables after the engagement ends?

Three practical tests. First, hand the SOW and ADRs to one internal senior engineer who wasn't in the sprint and ask them to summarize the build in 15 minutes — if they can't, the documents are too vendor-specific. Second, ask a competing vendor for a rough-order-of-magnitude bid against the deliverables; if they need to redo most of the work to quote, discovery wasn't portable. Third, check whether the acceptance criteria are testable without additional interpretation. Any one failure is a signal; two is a verdict.