Charging for an MVP before it exists: the case for a paid discovery phase

Founders are sometimes surprised when we quote a small fixed price for MVP discovery before quoting the actual build. It feels backwards: shouldn't the scoping conversation be free, like most sales calls are? For a real MVP, the discovery work itself is genuine, billable work, not a sales conversation, and treating it as free tends to produce worse outcomes for both sides.

A real discovery phase means interviewing the founder (and ideally a few prospective users) about the core assumption being tested, mapping the single workflow that needs to exist end to end, identifying what can be manual versus what must be built, and producing a written scope document with a specific price attached. That's a few days of genuine analysis and writing, not a 30-minute call.

When discovery is free, it's implicitly capped at whatever time an agency is willing to donate before getting a signed contract, which is usually not enough time to actually think carefully about what should and shouldn't be in the MVP. Paid discovery removes that time pressure and lets the agency (and the founder) genuinely think through the scoping decision instead of rushing toward a quote.

A founder unwilling to pay a modest fee for a properly scoped MVP plan is often not yet ready to pay for the MVP build itself, which typically costs many times more. Paid discovery is a cheap, low-risk way for both sides to test the working relationship and the seriousness of the project before either commits to a much larger engagement.

The scope document, wireframes, and technical recommendation produced during paid discovery belong to the founder, whether or not they proceed with us for the actual build. That's an important condition to look for in any paid discovery arrangement: you're paying for a deliverable you own, not just buying access to a sales pipeline.

A paid discovery phase for a typical MVP usually costs a small fraction of the eventual build cost, often in the low thousands of dollars depending on complexity. Given that a poorly scoped MVP can easily waste tens of thousands of dollars building the wrong thing, the discovery fee is one of the highest-leverage expenses in the entire process, not an added cost to resent.

Occasionally, a discovery phase surfaces a genuine problem with the underlying idea, an assumption that turns out to be untestable as originally framed, or a workflow that's actually two distinct products awkwardly combined into one description. A good discovery process is willing to say so directly, even though it means not immediately proceeding to a larger, more profitable build engagement, because a founder who trusts that honesty is a founder who comes back for the next project once the idea is properly reworked.

We've had discovery engagements end with a recommendation to pause and rethink rather than proceed straight to a build quote, and every one of those founders has told us later that the honest pause saved them from a build they would have regretted funding. That kind of outcome is a harder sell upfront than simply saying yes to everything, and it's the version of the relationship worth having.

A technical founder often arrives at discovery with a rough architecture already in mind, and our job shifts toward stress-testing that architecture against the actual assumption being validated rather than starting from a blank page. A non-technical founder needs more groundwork translating a business idea into a specific technical scope, which is usually a longer conversation but not a fundamentally different process, just a different starting point for the same set of questions.

Founders sometimes expect the discovery document to be a one-time reference they skim once before the build starts and then forget. In practice, the same document tends to get pulled back out repeatedly: during an investor conversation about what's actually being built, when onboarding a new hire who needs to understand the product's original scope, or six months later when deciding what the second version of the product should include. A discovery document written clearly enough to serve all of those purposes is worth more than one written purely to justify a build quote.

We write discovery documents assuming they'll outlive the initial build conversation, with enough context that someone who wasn't in the original meetings can still understand the reasoning behind each scoping decision. That's a slightly higher bar than writing internal notes for our own team, and it's the difference between a document that gets referenced for a year and one that gets filed away and forgotten within a month.

Some founders push back on paying for discovery at all, wanting to move straight into a build quote based on a conversation they've already had in their own head. We don't refuse this outright, but we're direct about the trade-off: skipping discovery means the build quote is based on our understanding of a verbal description rather than a document both sides have reviewed and agreed to line by line, and any gap between what was said and what was heard becomes a scope dispute later rather than a discovery-phase correction now.

In practice, almost every founder who initially resists paid discovery comes around once we walk through a real example of a scope misunderstanding from a past project that a short discovery phase would have caught early. The fee is small relative to the build. The cost of building the wrong thing is not.

At minimum: the specific assumption being tested, the one workflow that needs to work end to end, what's deliberately manual versus built, the metric that would count as validation, a rough technology recommendation, and a fixed price for the build phase. If a discovery deliverable is missing more than one of these, it's worth asking what exactly was paid for.