Fixed Price vs. Time and Materials: How Should You Pay for a Software Project?

Fixed price is a software development contract where scope, timeline, and total cost get agreed on before work starts, and the risk of anything costing more than expected sits with the squad or agency doing the work. Time and materials (T&M) is a contract where you pay for the actual hours worked, and that same overrun risk sits with the company hiring the team. Neither one is better in the abstract: fixed price works when scope is genuinely closed, and T&M works when scope is expected to change along the way. The real problem is that most software projects don't fully fit either extreme.

What is a fixed-price contract in software development?

In a fixed-price contract, the squad or agency quotes a closed amount for a scope defined in advance: this many features, this many screens, this many months. The company knows exactly what it's going to pay before a single line of code gets written, and that's the model's main appeal — predictable budget, no surprises. The flip side is that same closed number absorbs the estimation risk: if something takes longer than planned, whoever is doing the work loses margin, not the company.

This model works well when scope is genuinely closed before starting — a narrow redesign, a migration with a clear spec, an MVP with features already defined. It breaks down the moment a change request shows up mid-project, because any adjustment to the original scope means renegotiating the entire contract, not just adding one extra task.

What is a time and materials (T&M) contract in software development?

In a time and materials contract, the company pays for the actual hours the team spends on the project, plus whatever resources it uses along the way. There's no total amount fixed in advance: the final cost depends on how much work the project ends up taking. In exchange for that uncertainty, the company gets the flexibility to adjust priorities, add features, or change direction without renegotiating a closed contract every time something shifts.

The risk flips compared to fixed price: here the company carries it, not the squad. If scope grows without anyone controlling it, cost grows right along with it — and unlike fixed price, there's no ceiling that forces an explicit conversation before that happens. T&M works well when a project is inherently evolutionary (a product iterating on real feedback) and poorly when the company doesn't have the discipline to monitor progress week by week.

Why don't most software projects fit either pure model?

Both models start from the same assumption: that scope can be pinned down precisely upfront (fixed price), or that the company can monitor every change in real time (T&M). Industry data says neither assumption holds as often as it would need to. According to the Project Management Institute's (PMI) Pulse of the Profession 2018 — a survey of 5,402 organizations — 52% of projects completed in the previous 12 months had experienced scope creep, scope expanding without going through a formal approval process, up from 43% the same survey measured five years earlier. The three most cited causes of a project missing its objective were a change in organizational priorities (39%), a change in project objectives (37%), and inaccurate requirements gathering at the start (35%).

The cost of not handling this well is significant: large IT projects overrun their budget by 45% on average, according to a joint McKinsey & Company and University of Oxford study of 5,400 projects. With scope shifting in more than half of real projects, a fixed-price contract ends up in one change-order negotiation after another, and a time-and-materials one ends up with a bill that keeps growing without anyone having explicitly decided it should.

Does the billing model even matter if the project misses its goals anyway?

Less than it seems. The Standish Group, which maintains the largest database on IT project outcomes, found in its CHAOS Report 2020 that only 31% of projects finish within scope, time, and budget; 50% end up "challenged" — with cost overruns or scope cuts — and 19% get cancelled outright. That distribution doesn't depend on whether the original contract was fixed price or T&M: it depends on whether scope was well defined from the start, and on whether changes, when they show up, get handled as an explicit decision or slip in unmeasured.

Is there a middle ground between fixed price and time and materials?

In practice, more and more development squads and agencies bill per milestone: instead of fixing the cost of the entire project upfront, or leaving it open-ended by the hour, they define a scope and a bounded cost for the next chunk of work — two, four weeks — execute it, deliver it, and only then agree on the next one. Each milestone works like a mini fixed-price contract with a small, verifiable scope, instead of committing the whole project upfront.

The difference from a traditional fixed price is that the closed commitment only lasts as long as that chunk: if scope needs adjusting, it gets adjusted in the next milestone, with its own cost, instead of forcing a renegotiation of the entire contract or letting the change slip in unchecked.

How Zenit handles it: paid per milestone, not pure fixed price or open T&M

At Zenit, every milestone starts with an acceptance criteria signed by the company and the squad before a single line of code gets written: what that milestone includes, what's out of scope, and what evidence proves it's done. That agreement does the job traditional fixed price can't do without breaking at the first change, and the job open T&M never had: if something new shows up mid-milestone, it doesn't get added piecemeal — it becomes an explicit decision about whether it fits into the current milestone, with adjusted cost and timeline, or into the next one.

That early scope definition — the same one that, per the PMI data cited above, does the most to reduce the risk of a project spiraling out of control — is also the work Kaizen does before building the match: instead of starting from a form, it listens to the team's meetings and puts together a brief with scope, milestones, and decisions already documented before the squad starts working.

The question that actually matters isn't "fixed price or time and materials." It's what happens the day scope needs to change — because in most real projects, per the data cited above, that day comes — whether that conversation stays documented and bounded milestone by milestone, or turns into a full contract renegotiation or a bill that keeps growing without anyone seeing it coming.