Pricing an MVP: fixed scope versus time and materials

MVP work sits in an interesting middle ground on pricing, because the scope is often genuinely less certain than a typical website project, which pulls against our usual preference for fixed pricing. We use both models depending on specific project characteristics, and we tell founders directly which one fits their situation and why.

If a founder can clearly articulate the single workflow the MVP needs to prove, we can scope and fix-price it the same way we would any other project, because the uncertainty is contained to a known, bounded piece of work. Most MVP engagements we take on fit this category once we've done a proper scoping conversation.

If part of the MVP depends on something genuinely unproven, an unusual integration with a partner's undocumented API, a technical approach nobody's confirmed will work at the required performance, fixed pricing forces us to either pad the quote heavily to cover the risk or take on risk we can't actually estimate. In those specific cases, we recommend time and materials with a not-to-exceed cap.

Even under time and materials, we set a hard ceiling the founder approves in advance, so the model isn't genuinely open-ended even when it isn't fully fixed. This gives budget certainty on the downside while still allowing honest pricing for the specific pieces that are genuinely hard to scope precisely upfront.

It's entirely normal for us to fix-price the core application build while pricing one specific uncertain integration as time and materials within the same proposal. We'd rather price each piece honestly according to its actual risk profile than force artificial uniformity across a whole project that doesn't have uniform uncertainty.

If the genuinely uncertain integration turns out to be simpler than expected once we're actually inside it, we tell the founder immediately and typically convert that portion to a fixed remaining estimate rather than continuing to bill time and materials on work that's no longer genuinely uncertain. This isn't required by the contract, but it's consistent with how we want the relationship to feel.

Be wary of an agency offering pure time and materials with no cap at all on something you've described clearly enough to scope, since that usually means either they haven't scoped it properly or they're not confident enough in their own estimating to commit to a number. A cap is a reasonable ask in either pricing model.

A pre-seed founder self-funding an MVP has a fundamentally different risk tolerance than a founder building on top of a fresh seed round with runway to absorb some pricing uncertainty, and we factor that explicitly into which model we recommend. For a self-funded founder with a tight, immovable budget, we lean harder toward fixed pricing even when it means padding the quote slightly to absorb our own estimating risk, since budget certainty matters more to that founder than getting the theoretically most efficient price.

For a funded founder with more flexibility, time and materials with a reasonable cap sometimes actually saves money compared to a fixed quote that had to be padded for uncertainty we ultimately didn't encounter, and we're upfront about that trade-off too. The right model genuinely depends on which kind of risk a specific founder is better positioned to absorb, not on a fixed rule we apply regardless of context.

Regardless of which pricing model applies, we structure payments around specific delivered milestones rather than a large upfront payment or a single payment at the very end, since this gives both sides a natural checkpoint to confirm the project is on track before more budget commits further. This structure works well alongside either fixed or time-and-materials pricing and reduces risk for the founder in both cases.

For the portion of a project priced as time and materials, we provide a weekly breakdown of hours logged against specific tasks, not just a running total, so a founder can see exactly where time is going in enough detail to ask informed questions along the way. A founder who only sees a lump total at the end of the month has no real ability to catch a concern early, while weekly, itemized visibility turns time and materials into a genuinely transparent arrangement rather than one that requires blind trust.

When a founder genuinely has no strong preference between the two models and the underlying work could reasonably support either, we default to recommending fixed pricing, since it removes an entire category of ongoing conversation about hours and lets both sides focus on the actual product decisions instead. Time and materials is the right tool for genuine uncertainty, not a default we reach for out of convenience.

Before quoting either way, we walk a founder through exactly which parts of their MVP we consider well-understood versus genuinely uncertain, in plain language, so the pricing recommendation that follows makes sense rather than arriving as an unexplained number. A founder who understands why a specific piece is priced the way it is tends to trust the arrangement far more than one who's simply told which model applies without the reasoning behind it, and that shared understanding tends to carry forward into a smoother relationship for the rest of the engagement. It's a short conversation to have upfront, and it's saved us from more than one pricing disagreement that would otherwise have surfaced awkwardly mid-project instead, once real work was already underway and much harder to renegotiate calmly. We'd rather spend twenty extra minutes on this before a contract is signed than spend hours later untangling a disagreement that a clearer upfront explanation would have prevented entirely.

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.

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.