Why we charge for discovery: the case for a paid pre-engagement phase | Leval

Audience: AI startup CTOs, technical founders Reading time: 15 minutes

Every month we get a version of this message: "We have a great idea for an AI product. Can you give us a quote? We need it by Friday."

We can give you a number by Friday. It will be wrong. Not because we're incompetent, but because the information needed to give an accurate quote doesn't exist yet - not in your head, not in ours.

We charge for discovery. It typically costs $2,000-$5,000 and takes one to two weeks. This post explains why, what happens during that time, and why paying for discovery is almost always cheaper than the alternative.

The Number You Get Without Discovery

Here's what happens when a dev shop skips discovery and quotes directly from a conversation:

A founder describes their product in 30 minutes. The dev shop asks a few clarifying questions. The founder answers confidently. The dev shop multiplies their hourly rate by their best guess at hours, adds a buffer, and sends a number.

That number is a fiction. It's based on the founder's description of what they think they want, which is not the same as what they actually need to build, which is not the same as what the users will actually use.

A study from the Standish Group found that 31% of software projects are cancelled before completion, and 53% cost nearly double their original estimate. The primary cause is almost always the same: requirements that weren't well understood when the project started.

The $50,000 fixed-price quote you get in 48 hours becomes $80,000 when the "simple" third-party integration turns out to have no public API. Or $120,000 when the AI model you planned to use can't actually do what you need and you spend 6 weeks finding out. Or a cancelled project when you realize at week 10 that the data you need to make the product work doesn't exist in the format you assumed.

Discovery doesn't prevent all of these outcomes. It surfaces them early, when they're cheap to address.

What Goes Wrong Without Discovery

Three specific failure modes we've seen repeatedly.

The Undocumented API Problem

An AI document processing startup needed to integrate with their customers' existing accounting systems. Scope document said: "integrate with QuickBooks, Xero, and SAP." Sounded reasonable. Quote went out. Project started.

Week 3: the SAP integration turned out to require a middleware connector that costs $15,000/year per customer and takes 6-8 weeks to provision. This wasn't in the original scope because nobody asked the right questions about the integration path.

In a discovery phase, this comes up in the first week during technical feasibility review. The architecture changes: SAP integration is deferred to v2, the scope adjusts, the price adjusts. Everyone agrees before a line of code is written.

The Data Availability Problem

An AI pricing tool was supposed to analyze market data to recommend optimal prices. The model required competitor pricing data, historical sales data, and market trend data. The founder had access to their own sales data. Competitor pricing was "available online." Market trends were "from industry reports."

Discovery week: we looked at what "available online" actually meant. Competitor pricing scrapers violate most sites' terms of service and break whenever the HTML changes. Industry report data is paywalled, manually updated, and formatted differently per source. The product as described couldn't be built in the expected timeline with the expected budget.

The founder had two real options: build a tool that works only with their own data (simpler, faster, cheaper), or budget for data licensing and ETL pipelines (much more expensive). Without discovery, neither option would have been visible until week 6 of a 10-week project.

The AI Model Capability Problem

An AI contract review tool was scoped to "identify liability clauses and flag high-risk terms." Discovery week included a technical feasibility test: we ran 50 real contracts through Claude and GPT-4 with several prompt variations, scoring accuracy against manually reviewed examples.

Finding: identifying standard liability clauses worked well (92% accuracy). Identifying whether a specific clause was "high-risk" in context required legal judgment that the models weren't consistently applying - accuracy dropped to 67% on ambiguous cases. That's below the threshold where the tool would be trustworthy enough for actual business use.

The product needed either a human review step (for low-confidence outputs) or a more narrow scope (flag specific clause types instead of assessing risk). Both options changed the product significantly. Without the feasibility test in week 1, this would have become apparent during QA at week 8.

What Actually Happens in Discovery

Discovery isn't requirements gathering. Requirements gathering is what you do when you already understand the problem and the solution. Discovery is what you do when you don't yet have enough information to commit to a solution.

A two-week discovery at Leval produces four outputs.

1. Technical Feasibility Assessment

We test the riskiest assumptions before committing to build around them. For AI products: does the model actually perform well enough on your specific data? What accuracy can you realistically expect? What's the latency at your expected load?

For integrations: does the API actually support what you need? Is there rate limiting that affects your use case? Are there data format mismatches that require transformation?

For data processing: is the data in the format you assumed? How clean is it? What preprocessing is required?

These tests take 2-3 days and cost a fraction of what it costs to discover the answers at week 8.

2. Scope Document with Acceptance Criteria

Every feature that makes it into scope gets written down with acceptance criteria: how we'll know it's done. Not "AI analyzes contract" but: "AI extracts all clauses of type X, Y, Z from a PDF contract under 100 pages, returns structured JSON within 30 seconds, with confidence score per clause. Clauses with confidence below 0.7 are flagged for human review."

This document becomes the contract. If the acceptance criteria are met, the project is done. If you want something the acceptance criteria don't describe, that's a change request - assessed separately.

This is what makes fixed-price delivery possible. Fixed price requires fixed scope. Fixed scope requires acceptance criteria. Acceptance criteria require discovery.

3. Architecture Decision Record

Before writing code, we document the key architectural decisions: data model, API design, external integrations, auth approach, cloud infrastructure, AI model choice. Every decision includes the alternatives considered and why we chose what we chose.

This document exists so that 6 months from now, when a developer asks "why did we use Kafka here instead of a simple Redis queue?", there's an answer that doesn't require archaeology through Slack history.

It also surfaces architectural risks early. "We're planning to use this API for real-time updates" - fine, but the API has a 5-second polling minimum. Does that work for your use case? Better to know before building.

4. User Flow Validation

Before writing the architecture doc, we map the critical user flows step by step. Not wireframes - a text description of every state a user can be in and every action they can take.

This sounds tedious. It catches real problems. "User uploads a contract" - okay, what file formats? What's the max size? What happens if it's password-protected? What happens if the PDF is scanned (image-based) rather than text-based? OCR adds 15-30 seconds of processing time and requires a different processing pipeline. Was that in the original scope?

User flow validation forces edge case thinking before anyone has written code. Edge cases found in discovery cost 2 hours to handle. Edge cases found in QA cost 2 days.

5. Fixed-Price Quote

At the end of discovery, we give you a quote with a single number - not a range, not an hourly estimate, not a "depends on scope" answer. The number covers development through deployment. It doesn't change unless the scope changes.

This is possible because by the end of discovery, we understand the scope well enough to commit to it.

The quote includes what's explicitly out of scope - features that came up in discovery but didn't make the cut for the first version. This list matters because it sets expectations: when you ask for one of those features after launch, you know it's a change request, not something that should have been included.

What Discovery Looks Like Week by Week

Day 1-2: Kickoff call, stakeholder interviews, documentation review. We read everything you have - pitch deck, product brief, competitor research, any prior technical specs. We identify the three to five highest-risk assumptions that need testing.

Day 3-5: Technical feasibility testing. We run experiments against actual APIs, actual AI models with sample data, actual data sources. We're not theorizing - we're testing. Every assumption on the risk list either gets validated or becomes a finding that changes the scope conversation.

Day 6-8: Scope doc drafting. We write the acceptance criteria for each in-scope feature based on what we learned from feasibility testing. We share this with you and iterate - usually two rounds of feedback before it's final.

Day 9-10: Architecture doc and quote. Final architectural decisions documented, quote prepared. End-of-discovery call to walk through findings, answer questions, agree on next steps.

You should expect to spend about 4-6 hours of your own time during discovery: one kickoff call, one mid-point check-in, one end-of-discovery review. The rest is on us.

The Questions Discovery Answers

At the end of a well-run discovery, you should be able to answer:

• What exactly is in scope for v1, in specific enough terms that a developer can build it without asking you?
• What is explicitly not in scope, and what's the plan for v2?
• What are the riskiest technical assumptions, and have we tested them?
• What external dependencies does the project have, and what's the status of each?
• What's the fixed price for development, and what does it cover?

If you can't answer all of these before development starts, you're taking on risk that discovery would have addressed.

The Math on Discovery Cost vs. Scope Failure Cost

Discovery costs $2,000-$5,000 and takes 1-2 weeks.

Discovering a major scope problem at week 8 of a 12-week project typically means:

• 2-4 weeks of rework at $8,000-$15,000/week team cost
• Timeline slip that affects launch and fundraising
• Re-scoping conversations that add another week of back-and-forth
• Sometimes: cancelled project with sunk cost

The break-even point for discovery is finding one problem that would otherwise surface at week 4 or later. In our experience, every project has at least one such problem. Discovery pays for itself.

The counterargument founders make: "We don't want to spend $3,000 to learn about problems. We want to start building." This is understandable. It's also the reasoning behind most of the cancelled-at-week-10 projects we've been called in to rescue.

When Discovery Isn't Necessary

In fairness: three cases where discovery is less valuable.

You've built this before. If you've built and shipped the same type of product, you already understand the domain well enough to scope accurately. A founder on their third B2B SaaS tool with similar architecture doesn't need as much discovery as a first-time founder building an AI product in a new domain.

The scope is genuinely small and well-defined. If you need a webhook integration between two systems with documented APIs, and you've already tested both APIs work the way you think they do - that's a well-understood problem. Extensive discovery adds process without value.

You're doing pure research. If the goal is to explore whether something is technically possible, not to commit to building it - that's a different engagement. We offer technical research sprints for this case.

For everything else - new product domains, AI feature development, multi-system integrations, anything where the riskiest assumption hasn't been tested - discovery is the cheapest risk mitigation available.

How Discovery Works with Leval

Our discovery engagements run one to two weeks, with a team of one architect and one specialist (ML engineer for AI projects, integration specialist for connector-heavy projects).

Deliverables: feasibility test report, scope document with acceptance criteria, architecture decision record, fixed-price quote for development.

Discovery cost is deducted from the development project price if you proceed. If after discovery you decide not to proceed - you paid for the information that led to that decision, which is the right outcome.

The conversation starts with a 45-minute call where you describe what you're trying to build. We tell you honestly whether discovery is warranted, what we'd focus on, and what we'd expect to find. No pressure to proceed.

Start the conversation.