Two vendors bid on the same product. One quotes a fixed price. The other quotes time and materials. Both proposals sound reasonable until you ask a harder question: who eats the cost when the scope changes, and how often will that happen? A Norwegian study of 35 public software projects found an 83% success rate under time and materials versus 38% under fixed price, and it also noted that the fixed-price projects spent 20 to 30% longer in upfront planning to get worse outcomes. That gap is not really about billing. It is about how each contract handles what nobody knows on day one.
This guide is for anyone choosing between the two models on a real project, particularly a software or product build where scope will shift as you learn. The goal is not to declare a winner. It is to help you match the contract to the work, and to spot the moment when your instinct to lock in certainty is quietly making the project more expensive.
The Real Trade Is Risk, Not Billing
A fixed price contract sets one number for a defined deliverable, and the vendor absorbs the risk that the estimate was wrong. A time and materials contract bills for actual hours and materials at agreed rates, and the buyer absorbs the risk that scope will grow. NetSuite’s breakdown of the two models describes the mechanics well, but the mechanics are downstream of the real decision, which is where uncertainty gets absorbed and paid for.
Fixed price feels safer because the total is written on the page. What is not written on the page is the risk premium. Multiple practitioner sources put that premium at 15 to 30% of the bid, sometimes higher on ambiguous work. You pay it whether the risks materialize or not. If the project goes smoothly, you overpaid. If it does not, you still fight over what counts as scope.
Time and materials removes that premium but adds a governance cost. If nobody on your side is watching burn, priorities, and demos, you get the worst version of T&M: the meter runs, nice-to-haves creep in, and you arrive at a budget cap with the core still unfinished. PMI research summarized by industry analysts puts the average T&M software overrun at roughly 23% when governance is weak, and 55% of projects experience scope creep with an average 27% cost impact.
The failure mode of both models is the same. Someone commits to a pricing structure before the scope is genuinely understood.
What Each Model Actually Includes
Under a fixed price, the vendor is not just quoting labor. They are quoting an opinion about how much labor the work will require, plus a cushion. That cushion has to cover unknown integrations, missed requirements, personnel changes on their side, and the change-order fights they know are coming. Buyers rarely see that cushion itemized, which makes fixed-price quotes look cheaper than they are on the day scope moves.
Under T&M, the vendor is billing for what actually happened. That makes cost visible line by line. Time sheets show who worked on what and for how long. Weekly demos show what got built. In exchange, the buyer has to run a real product cadence: review often, decide fast, and be willing to kill features. That is a management burden fixed-price contracts hide but do not eliminate.
| Dimension | Fixed price | Time and materials |
|---|---|---|
| Who carries scope risk | Vendor, priced in | Buyer, paid as incurred |
| Budget certainty at start | High on paper | Bounded by cap or sprint budget |
| Cost of changing your mind | Change order with margin premium | Reprioritize the backlog |
| Vendor incentive | Finish agreed scope efficiently | Stay adaptive, keep momentum |
| Buyer effort required | Heavier at spec, lighter mid-flight | Steady throughout |
| Best fit | Stable, well-specified scope | Discovery, iteration, uncertainty |
Where Fixed Price Actually Works
Fixed price is not a bad model. It is a bad match for uncertain work. When the scope is well documented, the integrations are known, the acceptance criteria are testable, and the team on your side does not need to iterate to figure out what the product should be, fixed price is honest and often cheaper.
KodeKX’s 2025 analysis put the practical threshold around 80% requirements definition. Below that, fixed price introduces hidden costs averaging 27% of total spend, largely through change orders and quality compromises. Above that, the risk premium is small and the certainty is real. Reasonable candidates for fixed price include a data migration with a documented source and target, a compliance package with a defined checklist, a marketing site with locked wireframes, or a bounded feature added to an existing product.
The mistake is using fixed price for an MVP with an evolving user story. The vendor knows scope will move. They price for that. Then the change-order economics take over. Once you are locked in, you have lost competitive leverage on every subsequent change, and the vendor recoups the low bid on margin-heavy amendments.

Where T&M Actually Works, and Where It Falls Apart
Time and materials shines when the work involves genuine discovery: an early-stage product, an AI feature where the model behavior is not yet known, a rebuild where the legacy system’s quirks will only surface once you touch them. In these cases, the buyer-side analysis from Launch Day Advisors is worth reading, because it treats the contract as risk allocation rather than a commercial preference. T&M lets the team learn, adjust, and converge on the right product rather than the specified one.
T&M falls apart when the buyer treats it as autopilot. There is no built-in convergence pressure. Without sprint budgets, not-to-exceed caps, a prioritized backlog, and an empowered product owner willing to say no, the meter keeps running. The pattern practitioners describe is roughly 40% of budget spent on nice-to-haves before the core is complete. The fix is not to switch contracts. The fix is to install governance.
A workable T&M setup usually looks like this: sprint-level budgets with a visible burn chart, a not-to-exceed cap for the phase, weekly demos with the actual product owner present, a stop-loss threshold that forces a leadership review if you cross it, and outcome metrics rather than task completion. If those are missing, T&M becomes the runaway meter clients fear, and the fear is justified.
Why Most Serious Projects End Up Hybrid
The pattern experienced practitioners land on is not fixed price or T&M. It is fixed price for what can be bounded, T&M for what needs to be discovered, and both stitched together so the contract type matches the risk profile of each phase.
The most common structure is a fixed-price discovery phase followed by T&M build. Discovery is short, tightly scoped, and produces a real specification: user flows, technical decisions, integration list, risk register, effort estimate. That work is bounded enough to price. Once discovery ends, you know enough to run the build on T&M with confidence, or to convert to a much tighter fixed price for well-understood pieces. We use this pattern in our product design and discovery work because it is the only structure that consistently keeps buyers and vendors on the same side of the table.
When we built Workform, an AI MVP for a project management consultant, the initial concept was “an AI assistant that helps project managers with everything.” A pure fixed price on that brief would have been fiction. Discovery narrowed the scope to a focused MVP that ingests and connects data from Slack, email, Asana, and meetings. Only after that reframing did estimates mean anything. Committing to a build price on the original brief would have produced the exact adversarial dynamic fixed price is meant to prevent.
Other hybrid patterns worth knowing:
- Fixed-price milestones inside T&M, where discrete deliverables (a payment flow, an admin panel) are quoted separately once their scope is stable.
- T&M with a not-to-exceed cap, which gives buyers a hard ceiling and vendors flexibility below it.
- Fixed price for low-volatility elements, T&M for uncertain ones, common in construction and useful in software too when parts of the system are commodity work.
How to Decide, Practically
The decision is less about the project as a whole and more about each phase of the work. A few questions that usually settle it:
- Can you write testable acceptance criteria today? If yes, fixed price is viable. If you are still describing the product in analogies, you are in discovery.
- How often will your team be available to review work? If the answer is “monthly if lucky,” fixed price with strong specs is safer than T&M. T&M without decision-making capacity turns into billed drift.
- How much of the risk is on the buyer’s side, and how much on the vendor’s? Unknown integrations, unclear users, and evolving business rules are buyer-side risks that fixed price will not absorb well, no matter what the contract says.
- Are input costs stable? In construction and infrastructure, tariff shocks (Section 232 steel tariffs doubled from 25% to 50% in June 2025) and 5 to 7% annual materials inflation make long-duration fixed prices structurally hazardous without escalation clauses. Software has less of this, but multi-year fixed prices still expose vendors to labor cost changes they will price in defensively.
Before any of that, know what a realistic number looks like. Our software development cost estimation guide and the deeper custom web app development cost breakdown give real ranges by product type, so you can spot when a fixed-price quote is padded and when it is realistic.
What to Insist On in Either Contract
A good contract does not just state the price. It tells both sides how to behave when the product changes. Fixed price or T&M, the failure points are almost always in the same places, and the fixes are similar.
- Testable acceptance criteria for each deliverable. “Done” needs to mean the same thing to both sides. DocuWriter’s guide to writing business requirements is a useful reference here, because vague requirements are what turn contracts into arguments.
- An explicit change process. Who signs off. How it is priced. How fast a decision must come. Under fixed price, this is where money quietly leaves. Under T&M, this is where scope quietly grows.
- A weekly or biweekly cadence with a live demo. Surprises compound. Reviews stop them.
- Visible burn under T&M: sprint budgets, a not-to-exceed cap, and hour tracking you can see without asking.
- An assumptions and exclusions list under fixed price. Everything not written down is a future change order.
Before signing, run the language through an AI contract review tool to flag one-sided change-order clauses, missing acceptance criteria, and vague indemnity terms. It is a cheap sanity check for a document that will govern the next six months.
If a vendor will not define the decision process, they are asking you to absorb the ambiguity later. The contract that looks simplest at signing is often the one that costs most at delivery.
The Practical Recommendation
For most product work with any real uncertainty, run a short fixed-price discovery phase first, then move to T&M or tightly scoped fixed-price milestones for the build. The discovery phase should produce a specification concrete enough that either party could hand it to a different team and get a similar estimate. If it cannot, the work is not ready to be priced.
A fixed price is the way to go for work that has to be stable; one simply accepts the premium as the price of certainty. When the work is of an exploratory nature, T&M is preferable, provided there is an investment in the proper governance to oversee it. Then there are all the software projects in between, and for those a hybrid approach is called for.
Our MVP development process is designed to put any questions to rest when it comes to the scoping required before development can commence. As for the more difficult matter of how to put together a team once the contract is in place, the tradeoffs are laid out in our guide on hiring a dedicated development team. In the end, the right contract will reflect the true clarity of your product rather than serving to obscure what is still unknown.
Saeedreza Abbaspour is the CEO of Refact, where he works across product, engineering, and sales. He sets the studio’s direction while staying closely involved in the work itself, from shaping product strategy and UX architecture to helping define the technical systems behind Refact’s projects. His role connects business thinking with hands-on product execution, giving him a practical view of how software should be planned, built, launched, and improved. At Refact, Saeedreza focuses on building a studio that can move quickly, solve real client problems, and turn ideas into reliable digital products.
More from Saeedreza Abbaspour



