Fixed price or time and materials? How to contract custom software without paying twice

Two quotes for the same system are on your desk. The first says €60,000, fixed. The second says €95 an hour, with an estimate of 500 to 700 hours, so somewhere between €47,500 and €66,500. The first one feels safer, because you know the number.

Often it is not. A fixed price does not remove the risk of a wrong estimate. It only decides who carries it, and how you pay for it.

What each model really means

Fixed price: the supplier promises a defined result for a defined price. If the work takes longer than estimated, the supplier pays. That is why they add a buffer to the price and protect the agreed scope: every change becomes a change request with its own quote.

Time and materials: you pay for the time actually worked, at an agreed rate. If the work takes longer, you pay. In return, you can change direction at any time without renegotiating the contract.

	Fixed price	Time and materials
Who carries the estimation risk	The supplier, priced in as a buffer	You
Changes during the project	A change request and a new quote	A new priority in the backlog
What you need before you start	A detailed specification	A clear goal and priorities
Budget control	One number, as long as nothing changes	A monthly cap and regular reviews
What the supplier is paid for	The agreed scope, in as few hours as possible	Work you are happy to keep paying for
Fits best	Small, clearly bounded work	Anything that will change along the way

Why fixed price often ends up more expensive

Estimating software is hard, for everyone. Research by McKinsey and the University of Oxford on more than 5,400 IT projects found that large projects run on average 45 % over budget and 7 % over time, while delivering 56 % less value than predicted. A fixed price does not make estimating easier. It moves the argument about the estimate into the contract.

In practice, it shows up in four ways:

1. The buffer. A supplier who guarantees the number adds a margin for the unknowns. You pay for it even when nothing goes wrong.
2. Change requests. Business software almost always changes once users see it. “The report needs one more column” is two days of work, and in a fixed-price project it is a new quote, a new approval and a new invoice.
3. Savings where you cannot see them. When hours run short, they are saved where nobody looks at acceptance: tests, documentation, security.
4. The argument at the end. Is this a bug or a change? Every unclear sentence in the specification becomes a discussion just when you want to go live.

There is also a legal difference. In Germany, a fixed-price project is usually a Werkvertrag (§ 631 BGB): the supplier owes a result, and you formally accept it (Abnahme, § 640 BGB). Time and materials is usually a Dienstvertrag (§ 611 BGB): the supplier owes the work, not a specific result. That changes warranty and who carries which risk. Other countries make similar distinctions. This is not legal advice; have a lawyer look at the contract.

When a fixed price makes sense

• Small, clearly bounded work. One integration, one report, an upgrade from .NET 8 to .NET 10 where the scope is known.
• A specification that will not change. For example, an interface defined by a regulator or by another system.
• The analysis at the start. A few weeks to understand the processes, write the requirements and estimate the rest. This is the safest place for a fixed price.

When time and materials makes sense

• The requirements will change once users see the first version. With business software, that is almost always.
• Long-term development and maintenance, where the work never really ends.
• Taking over an existing system, where nobody knows how much is hidden in the code. More on that in our article on taking over a .NET application.

The hybrid that works best in practice

1. Step 1Analysis at a fixed price
2. Step 2First version, monthly cap
3. Step 3Demo every two weeks
4. Step 4Development in monthly blocks

The first decision has a known price: an analysis of one to three weeks, after which you have the requirements, a rough architecture and an estimate in ranges. From then on, the work runs on time and materials with a monthly cap, and you see working software every two weeks. You are never committed to more than a month, and if the collaboration does not work, you leave with the analysis and the code.

How to protect yourself with time and materials

• A monthly cap in writing. The supplier warns you at 80 % of the budget, not after it is gone.
• A demo every two weeks. Working software, not status reports.
• Hours per task. Every hour linked to a ticket you can open.
• The code in your repository from day one.
• Monthly notice. If it does not work, you can stop.
• Estimates in ranges, updated regularly. “Three to five weeks” is honest. “Exactly 27 days” is not.

Red flags in a fixed-price quote

• A price without a detailed specification. The supplier has priced their own assumptions, not your system.
• “Changes billed separately” without a rate or a process.
• No acceptance criteria. Nobody knows when the work is done.
• No word about tests, documentation or handover.
• A price far below the others. The difference usually comes back through change requests.

Realistic price ranges are in our article on what custom business software costs, and day rates in the one on .NET freelancer hourly rates.

How to write a specification that suppliers can price fairly is covered in our article on the software requirements document.

How we work

This is exactly how we work. ProCoding is a .NET studio in Split, Croatia, and we build and maintain business applications in .NET and Blazor. We usually start with a short analysis at an agreed price, then work in monthly blocks with a cap, a demo every two weeks and the code in your repository from day one, cancellable month to month. For larger projects, you can also have a freelance .NET developer full time for the length of the project. The first step is a free 30-minute call, where we look at your project and at the quotes you already have.

Sources

• Delivering large-scale IT projects on time, on budget, and on value, McKinsey, 1 October 2012
• § 631 BGB, Werkvertrag, § 640 BGB, Abnahme and § 611 BGB, Dienstvertrag, Gesetze im Internet