The Setup: A 9-Month Enterprise Project
If you are about to commission a custom software project, you will encounter two pricing models: fixed price and Time and Material (T&M). Every software house has an opinion on which is better, and most of those opinions are shaped by which model the vendor prefers to sell.
This article takes a different approach. Instead of making an argument, it runs the numbers. We walk through the same 9-month enterprise project under both models and show where the money goes, where the risk sits, and who carries the cost when things change. The examples are based on projects we have delivered or seen delivered at codelabs.rocks over the past 10 years.
Imagine you are commissioning a custom platform: a mid-complexity business application with a backend, a web frontend, integrations with two external systems, and a user base of around 5,000 people. The team consists of 3 developers, a project manager, and a part-time QA engineer.
At an EU nearshore rate of 70 EUR per hour (blended across roles), the baseline estimate is:
- Team capacity: approximately 800 hours per month (5 people, mixed utilisation)
- 9 months of delivery: approximately 7,200 total hours
- Baseline cost at face value: approximately 504,000 EUR
Now let us see what happens to that number under each model.
Fixed Price: What the Contract Says vs What Actually Happens
The quote
A fixed-price vendor takes the requirement specification, estimates internally, and adds a risk buffer. Industry standard is 25 to 40 percent on top of the honest internal estimate. The client sees a single number.
- Internal estimate: 504,000 EUR (7,200 hours at 70 EUR)
- Risk buffer at 30 percent: 151,200 EUR
- Quoted price: 655,200 EUR
The client signs for 655,200 EUR feeling confident about the total budget. But note: 151,200 EUR of that is insurance the vendor is charging you for the privilege of accepting risk. If nothing goes wrong, the vendor pockets that margin. If something does go wrong, the vendor uses it to absorb the overrun without losing money.
What changes during the project
Nine months is a long time. Across a project of this length, scope changes are not a risk; they are a certainty. The business learns more about what it needs, the market shifts, users provide feedback on early releases, and technical discoveries force adjustments.
In a fixed-price contract, every change triggers a formal change request. The vendor re-estimates the impact, adds another risk buffer, and sends you an amendment to sign. Typical change request dynamics on a 9-month project:
- 3 to 6 significant change requests over the project lifetime
- Each change request adds 10,000 to 40,000 EUR
- Cumulative change request cost: 60,000 to 150,000 EUR
- Administrative overhead per change: 2 to 5 days of negotiation time on both sides
The real total
- Original contract: 655,200 EUR
- Change requests (conservative): 80,000 EUR
- Your time spent on change negotiations: difficult to quantify, but real
- Actual total: approximately 735,000 EUR
And that is the optimistic scenario. The pessimistic scenario involves the vendor discovering mid-project that the specification was ambiguous on three critical points. Features get descoped to stay within budget, the client receives a technically correct but practically incomplete product, and a second engagement is needed to build what was left out.
Time and Material: What the Contract Says vs What Actually Happens
The agreement
A T&M contract specifies an hourly rate and a team composition. There is no total project price. Instead, the client pays for actual hours worked, reviewed transparently at the end of each sprint.
- Hourly rate: 70 EUR (blended)
- Estimated team capacity: ~800 hours per month
- No risk buffer in the rate (the vendor is not carrying fixed-price risk)
What changes during the project
The same scope changes happen, because the same business learning occurs. The difference is how they are handled. In T&M with 2-week sprints, a scope change is a reprioritisation, not a contract amendment. The product owner moves items up in the backlog, other items move down, and the team continues working in the next sprint. No change request document. No re-estimation cycle. No negotiation.
The trade-off: the client does not have a guaranteed total price. The project could run longer or shorter than planned. This is real uncertainty, and it is the reason many buyers default to fixed price. But compare what happens in practice:
- Months 1 through 6: the project runs roughly on pace. Monthly spend is predictable because team composition is stable. Cumulative cost: approximately 336,000 EUR.
- Month 7: a major scope change reduces one module and expands another. The team adjusts within the same sprint. No change request. Cost impact: zero additional overhead.
- Months 8 through 9: the project wraps up. Some features originally planned are deprioritised because the client learned they were less important than expected. The team delivers what matters most, not what was specified 9 months ago.
The real total
- Actual hours worked: approximately 6,800 (slightly below the 7,200 estimate because deprioritised features saved time)
- Total cost: approximately 476,000 EUR
- Change management overhead: zero formal change requests
- Administrative burden: negligible (sprint reviews replaced negotiation cycles)
Side by Side
Here is the comparison at a glance:
Quoted/estimated cost: Fixed Price 655,200 EUR vs T&M 504,000 EUR (estimate)
Risk buffer: Fixed Price 151,200 EUR (baked in) vs T&M 0 EUR
Change requests: Fixed Price ~80,000 EUR vs T&M 0 EUR (reprioritised)
Actual total: Fixed Price ~735,000 EUR vs T&M ~476,000 EUR
Budget certainty at signing: Fixed Price High (illusory) vs T&M Lower (honest)
Scope flexibility: Fixed Price Low (change requests) vs T&M High (backlog reprioritisation)
Admin overhead: Fixed Price High (negotiations) vs T&M Low (sprint reviews)
Where the Real Risk Lives
The conventional wisdom is that fixed price reduces risk for the buyer. In practice, it shifts the label of risk without reducing the substance.
In fixed price: you accept higher cost upfront (the risk buffer) in exchange for a number you can put in a budget spreadsheet. But when changes happen, you pay again through change requests, and you lose negotiating leverage because the vendor controls the scope interpretation. The risk has not disappeared; it has been renamed.
In T&M: you accept uncertainty about the total, but you gain control over every euro spent. You see hours every sprint, you approve work every two weeks, and you can stop the engagement at any sprint boundary if the project is not delivering value. Your maximum exposure at any point is two weeks of team cost, not the full remaining contract value.
The paradox: fixed price feels safer but costs more. T&M feels riskier but gives you more actual control over the outcome.
When Fixed Price Genuinely Makes Sense
We operate T&M exclusively, but we are not ideological about it. Fixed price can work when:
- The scope is truly known and stable (rare in custom software, common in integration or migration projects with well-defined inputs and outputs)
- The specification is detailed enough that both sides agree on exactly what done means before work begins
- The project is short (under 3 months) and scope changes are genuinely unlikely
- Regulatory or procurement requirements mandate fixed-price contracting
If none of these apply, and you are building a custom product where business learning will evolve the scope, fixed price is costing you more than T&M would, every time.
What to Ask Your Vendor
Whether you choose fixed price or T&M, these questions will clarify what you are actually paying for:
- What percentage of your fixed-price quote is risk buffer?
- How are change requests priced and approved? What is the average change request cost and turnaround time on a project like mine?
- In T&M, how do you control scope creep? What mechanisms prevent the project from running indefinitely?
- Can I see a monthly cost breakdown from a comparable past project?
- What happens if I need to pause or end the engagement early?
The Bottom Line
Fixed price and T&M are not equally valid options for every situation. For custom software projects longer than three months with evolving requirements, T&M consistently delivers more value at lower total cost, provided the client is willing to participate in sprint reviews and prioritisation.
At codelabs.rocks, we work exclusively on T&M because 10 years of delivery have shown us that it produces better outcomes for both sides. The vendor builds what actually matters instead of defending a specification that is already out of date. The client pays for real work instead of subsidising risk buffers they may never use. The relationship stays collaborative instead of becoming adversarial the first time someone says that was not in scope.
If you are comparing proposals and one is fixed price and the other is T&M, do not just compare the headline numbers. Compare the total cost including change requests, the scope flexibility, and the administrative overhead. The cheaper-looking option at signing is rarely the cheaper option at delivery.
