Fixed Price vs. Time and Materials for Software Projects

Contract type tends to come up late, after everyone has agreed on the technical approach and wants to get started. I would argue it deserves attention earlier, because it decides who pays when the work turns out to be harder than planned, and on software projects that happens often enough to plan for.

There are plenty of hybrids, but most agreements for software work are built on one of two structures.

Fixed price

The scope is defined and the fee is set. If the work takes longer than expected, the vendor covers the difference.

From the buyer’s side that sounds safer, and in the right circumstances it is. The complication is that a fixed price is only as solid as the scope underneath it. A vendor offering one responsibly has to allow for what isn’t known yet. When the scope is vague, that allowance grows, or the vendor draws the scope so narrowly that it no longer covers everything you needed. Changes after that go through a change order process, which protects both parties but slows things down.

In my view, fixed price fits best when the deliverable can be described precisely up front, the existing system is well understood (or the work is a bounded review or assessment), and predictable cost matters more to you than flexibility.

Time and materials

You pay for hours worked at agreed rates, normally with a ceiling that can’t be exceeded without your approval.

More of the risk sits with the buyer, along with more of the control. You can change direction without renegotiating, and you don’t pay a premium for uncertainty that may never become a problem. In return, someone on your side has to review progress and spending against the plan on a regular schedule.

For federal work, time and materials is generally treated as a less preferred contract type and comes with requirements for justification and a ceiling price. Commercial buyers have more freedom, although I would still insist on a ceiling.

It suits work where the problem is clear and the solution isn’t yet, such as debugging, performance tuning, or early product development. It also works when priorities are likely to shift, provided the buyer has someone available to manage the work closely.

The two side by side

	Fixed price	Time and materials
Who absorbs overruns	The vendor	The buyer, up to the ceiling
Changing the scope	Change order	Simple
Scope needed up front	Detailed	Clear goals and a ceiling
Oversight from the buyer	Lighter	More involved

Splitting the work

For larger projects I tend to favor using both. Start with a short fixed-price discovery phase or architecture review whose only job is to turn the unknowns into a written scope. Once that exists, price the build as fixed price if the review made it predictable, or as time and materials with a ceiling if it did not.

That way you spend a modest, capped amount to learn what the real project is before committing to the large one, which I think is about the cheapest insurance a software buyer can get.

How we handle it

Whichever structure we use, we agree on deliverables, timing, and fees before work begins. If we think a fixed price would force us to pad the number or cut the scope too far, we will say so and explain our reasoning. An architecture review is often a sensible place to start.