Fixed price vs time and materials: which is right for you?

The pricing model you pick shapes almost everything about a software project: how scope gets negotiated, who absorbs the surprises, and how much trust the two sides need. Buyers often assume fixed price is safer because the number is known up front. Sometimes it is. Often it just hides the risk somewhere less obvious. The track record for large software work is sobering: a McKinsey study with the University of Oxford of more than 5,400 IT projects found that big ones (initial budgets above $15 million) ran on average 45% over budget and 7% over time while delivering 56% less value than predicted. No contract wording makes uncertainty disappear. It only decides who pays for it. Here is how fixed price and time and materials actually behave once real work starts.

How each model really works

Under a fixed-price contract, the vendor commits to a defined scope for a defined price. You agree on exactly what gets built, they quote a number, and that number holds as long as the scope holds. The vendor carries the risk of overruns. If the work takes twice as long as estimated, that is their problem, not your invoice.

Under time and materials (T&M), you pay for the hours worked at agreed rates, plus any pass-through costs. Scope can flex as you learn. The vendor bills for effort, and you carry the risk of how much effort the work turns out to need. The two models are not good and bad versions of each other. They allocate risk differently, and the right choice depends on how much you actually know at the start. The same McKinsey and Oxford study found that software projects run the highest risk of cost and schedule overruns of any project type, and that the surveyed overruns totaled around $66 billion, more than the GDP of a small country. The point is not that software is uniquely doomed. It is that the estimate you sign is a starting hypothesis, and the contract decides who funds the correction. The Standish Group's CHAOS research is a useful reality check: only about 31% of software projects fully succeed on scope, schedule, and budget, so any model that assumes a first estimate will hold is betting against the base rate.

Where fixed price hides risk premiums

Fixed price feels safe because the number is fixed. The catch is that a competent vendor cannot commit to a price without protecting themselves against the unknown. They do that in two ways, and both cost you.

First, they pad the estimate. To promise a number, they price in a buffer for everything that might go wrong, so you often pay a premium for certainty even when nothing goes wrong. Second, they defend the scope. Once the price is locked, every request that was not written down becomes a change order, because their margin depends on holding the line. That pressure is real because scope moves on most projects: PMI found 52% of projects experience scope creep, so the change-order fight is closer to the default than the exception. The result can be a system that technically matches the spec while missing what you actually needed, because the spec was written before anyone understood the problem. The hidden costs of custom software often surface exactly here.

When T&M protects both sides

Time and materials gets a bad reputation as a blank check, and without controls it can be. With controls it is often the more honest model. When requirements are genuinely uncertain, T&M lets the team build the right thing as understanding improves, rather than the thing that was guessed at in a kickoff meeting. That adaptive approach is not just a preference. Standish's 2020 data put the success rate of agile projects at 42% versus 13% for waterfall, and T&M is the billing model that lets a team actually work that way.

It protects the vendor from having to pad, so you are not paying for a buffer you may not use. It protects you because you can change direction without triggering a contract fight, and because you see where the hours go. The guardrails that make T&M safe are straightforward: a not-to-exceed cap so spend cannot run away, sprint-level reporting so you see progress and burn, and the ability to stop at any sprint boundary. With those in place, you get flexibility without signing an open-ended commitment.

Managing scope under each model

Scope management looks completely different across the two models.

• Under fixed price, discipline lives in the change-order process. Every deviation from the spec gets estimated, priced, and approved in writing before work proceeds. This works when scope is stable and you can define "done" precisely.
• Under T&M, discipline lives in prioritization. Because you are paying for effort, the job is to keep the team pointed at the highest-value work each sprint. A well-run T&M engagement uses a prioritized backlog and a demo every cycle so you can steer.

Either model fails without the matching discipline. Fixed price without clear acceptance criteria turns into disputes about what the spec meant. T&M without prioritization turns into hours spent on the wrong things. If you are also negotiating the legal side, custom software contract terms you should negotiate covers how acceptance and change orders should read.

Hybrid: fixed discovery, T&M build

The model that fits the most projects is a blend. Start with a fixed-price discovery phase: a short, bounded engagement where the team digs into requirements, sketches the architecture, and produces a real backlog with estimates. The price is small and defined, so your risk is capped while the biggest unknowns get resolved. This directly attacks the McKinsey finding that overruns grow with duration and scale, since the same study noted that every additional year on a project raises cost overruns by about 15%. Resolving the unknowns early keeps the expensive stretch shorter and better understood.

Then build under time and materials, now that both sides actually understand the work. You have removed the reason fixed-price estimates get padded (nobody is guessing anymore) while keeping the flexibility to adjust as the product takes shape. Kadmoon works in two-week sprints with a working demo each cycle and measurable acceptance criteria in the contract, which is the natural rhythm for a T&M build with fixed-price discovery in front of it. You get predictability where it helps and flexibility where it matters.

The blend also fixes the trust problem that dogs both pure models. Under pure fixed price, the incentive is for the vendor to do the minimum that passes the spec, because every extra hour eats their margin. Under pure T&M with no controls, the incentive can run the other way, toward more hours. Fixed discovery followed by capped, reported T&M aligns the two sides: the discovery gives you a real number to plan against, and the sprint-by-sprint delivery lets you confirm you are getting value before funding the next stretch of work. You are never more than two weeks from a decision point where you can continue, adjust, or stop. That optionality is worth more than the false comfort of a single big number agreed before anyone understood the problem. It also keeps you far from the tail McKinsey called black swans: the 17% of large IT projects that overrun by more than 200% and can threaten the company that funded them.

A decision guide by project uncertainty

The cleanest way to choose is to ask how much you truly know.

Situation	Better fit
Scope is crisp, well-understood, unlikely to change	Fixed price
A hard budget ceiling matters more than flexibility	Fixed price, tight spec
Requirements are fuzzy or will evolve as you learn	Time and materials
Long-running product with an ongoing roadmap	T&M or dedicated team
New problem, real unknowns, want to move fast	Fixed discovery, then T&M

If a vendor insists on a firm fixed price for work nobody has scoped yet, treat that as a signal. Either the padding is large, or the change orders are coming. The stronger move is to buy a small discovery, learn what the project really involves, and then choose the model that fits what you found. When you want that laid out for your specific project, get a technical proposal. You can also read how to choose a software partner for the wider evaluation.