Pricing an MVP: fixed scope vs time and materials

Founders often default to wanting a fixed price for an MVP, since it feels like the lower-risk option. It's the right model when the scope is genuinely well-defined, and the wrong one when it isn't, because forcing a fixed price onto a genuinely uncertain scope just moves the risk into padding, not out of the project.

We walk every founder through both models honestly before quoting anything, including the ways each one can go wrong, since a founder who understands the tradeoff upfront makes a better decision than one who's simply told which model we're using without being shown why.

If a founder can describe the single workflow the MVP needs to prove in a sentence, and that workflow doesn't depend on integrations or technical unknowns nobody's scoped yet, fixed price is a reasonable, low-risk choice for both sides, and it's what we recommend by default in that situation.

The clarity test here is stricter than it sounds. A founder who can describe the workflow in a sentence but hasn't yet confirmed that a required third-party integration actually supports the behavior the MVP needs doesn't pass it, even though the description itself sounded clear. We check for that kind of hidden unknown specifically before agreeing a fixed number, since it's the most common way a seemingly well-defined scope turns out not to be.

When a founder is still actively deciding what the MVP even needs to include, forcing a fixed price at that stage means either the price gets padded heavily to cover the uncertainty, or scope gets locked prematurely in a way that produces a worse product. Time and materials, with a not-to-exceed cap and weekly visibility into hours spent, is the more honest model for a genuinely undefined scope.

The not-to-exceed cap matters more than the hourly rate itself, honestly, since it's what gives a founder the budget predictability they're actually looking for when they first ask for a fixed price. We set that cap based on a worst-case estimate of the scope as currently understood, which gives both sides a real ceiling to plan against even while the exact scope is still being worked out in detail.

A short discovery phase, billed time and materials, that ends in a concrete, specific scope document, followed by a fixed-price quote for the actual build: this hybrid captures the honesty of time and materials for the uncertain part and the predictability of fixed price for the part that's actually well understood by the time it's priced.

This is our default recommendation for most founders who arrive undecided between the two models, since it removes the pressure to guess correctly upfront. Nobody has to commit to a pricing model before there's enough information to price the work accurately, and the discovery phase itself, usually a week or two, is short enough that it doesn't meaningfully delay the overall timeline.

Budget predictability and appetite for ambiguity vary a lot by founder, independent of how well-defined the actual scope is. Some founders would rather pay a premium for a fixed number and total certainty even on a well-defined scope; others are comfortable with the variability of time and materials even on a genuinely uncertain one. We factor that preference in alongside the scope-clarity question, since the right pricing model is partly a scope question and partly a genuine risk-tolerance question.

We ask this preference question directly and early, rather than inferring it from how the founder talks about budget, since the two don't always correlate the way you'd expect. A founder with a genuinely tight budget sometimes still prefers the flexibility of time and materials, trusting themselves to manage the cap actively, while a well-funded founder sometimes wants a fixed number purely for the psychological relief of a settled decision they don't have to keep monitoring.

Setting a credible not-to-exceed cap requires enough discovery to estimate a genuine worst case, not just a comfortable middle estimate padded slightly. We walk through the scope's known unknowns explicitly with the founder before proposing a cap number, naming each specific area of uncertainty, an unconfirmed integration, an unscoped edge case, rather than folding all of that uncertainty into one opaque buffer percentage nobody can evaluate.

This transparency matters because a founder who understands exactly what's driving the cap number can make an informed choice about resolving that uncertainty faster, sometimes cheaply, before work even starts, which can lower the cap itself. A cap presented as a single unexplained number invites distrust; a cap built from a visible list of specific open questions invites a productive conversation about closing them.

If work approaches the not-to-exceed cap and the scope genuinely hasn't been completed, we surface that early, with real remaining work visible, rather than waiting until the cap is hit to have the conversation. Founders consistently tell us this early flag, given weeks rather than days before the cap would be reached, is what makes time-and-materials pricing feel trustworthy in practice rather than like an open-ended risk they're quietly exposed to.

Founders sometimes arrive believing fixed price is categorically safer, since the number is locked in regardless of what happens. That's only true if the underlying scope was actually well-defined; a fixed price on a badly-scoped project just moves the risk into an argument about what was originally included, which is a worse outcome for both sides than an honest, transparently capped time-and-materials arrangement would have been.

We'd rather walk a founder through this nuance upfront, even if it means a slightly longer initial pricing conversation, than let them default to whichever model sounds safer without understanding why. A founder who picks the right model for the right reason ends up with a much better working relationship over the life of the project than one who picked based on a surface-level assumption about risk.