Fixed price vs time and materials: how agencies price MVP projects

Almost every MVP quote comes in one of two shapes: fixed price, or time and materials. Founders often default to wanting fixed price because it feels safer, but it is not automatically the better option, and the wrong choice can cost you more than the price difference.

Fixed price: how it actually works

You agree a detailed scope up front, and the agency quotes a single number to deliver exactly that. It feels low-risk because the number is known in advance. The catch is in the word "exactly" — any change to scope, however small, typically triggers a change request and an additional fee, because the agency priced the specific thing you agreed, not the outcome you actually want.

Fixed price works well when the scope is genuinely well understood and unlikely to change — a known integration, a well-specified feature addition to an existing product. It works poorly for a true MVP, where the whole point is that you are still learning what the product needs to be.

Time and materials: how it actually works

You pay for the team's time, typically billed weekly or monthly, and scope can flex as you learn. This is a better match for genuine MVP work, where requirements are expected to shift as real user feedback comes in. The trade-off is less certainty about total cost, and it depends on trusting the team to use the time well — which is really a trust and track-record question, not a pricing-model question.

The hybrid most good agencies actually use

In practice, a lot of serious MVP work is quoted as a capped estimate within a range: a minimum and maximum cost based on a reasonably well-defined scope, with the understanding that minor scope changes are absorbed and larger ones are discussed openly rather than triggering a formal change-order process. Our own MVP cost calculator gives a range for exactly this reason — the real number depends on decisions you have not made yet.

Questions to ask before agreeing to either

• What specifically happens if we need to change scope once the build has started?
• Is the estimate based on a spec we have both actually agreed, or a rough brief?
• How often will we see working software, not just status updates?
• What is excluded from the price, and is that list in writing?

The pricing model matters less than how clearly those questions get answered. A fixed-price quote with an honest, detailed scope and clear change process can work fine. A time-and-materials engagement with no visibility into how the hours are spent is just as risky as the fixed-price horror stories founders tend to worry about.