The Software Contract Nobody Reads Closely Is Often the Reason the Project Goes Sideways

Note: This story was written with AI assistance and edited by me.

Note: An earlier version of this piece, "Fixed Price, Time and Materials, or Retainer? Choosing the Right Contract for Software Work," was published on DEV.

Software teams will spend weeks arguing over frameworks and databases, then accept whatever engagement structure appeared in the vendor's proposal without much thought. Later, when deadlines slip and tempers rise, the real cause often turns out to be that contract: a model that never matched the kind of work being done.

I have sat on both sides of these negotiations, first as a partner at a software consulting company that grew from about $6M to $60M in under three years, and later running a fully remote consultancy of my own. These are the three models I see most often, and how I decide between them.

Fixed Price

A fixed price deal promises a specific outcome for a specific fee. Buyers find it reassuring because the number does not move. Vendors accept it because well understood work can be delivered profitably.

It shines when the scope is truly settled: a small build with a clear specification, a migration with firm boundaries, or something the vendor has shipped many times.

Most software does not look like that. When requirements are still taking shape, a fixed price makes both sides act more certain than they are. Either the vendor adds a large cushion and the buyer pays for comfort, or the vendor bids low to win and then fights every change.

Signals it was the wrong choice: change requests outpace actual features, meetings keep circling back to what was or was not "in scope," and testing gets trimmed so the vendor can protect its margin.

Time and Materials

Here the buyer pays for the hours and expertise actually used. It fits work where the goal is clear but the path is not, such as new products, builds with heavy discovery, or integrations with tangled older systems.

That flexibility is valuable. Priorities can shift each week without reopening the contract. The trade is that risk now sits with the buyer, and without good visibility the hours can creep upward unnoticed until the bill arrives.

It works when the buyer owns and actively ranks a clear backlog, sees working software demonstrated regularly and receives honest reports that set spend against progress.

Signals it was the wrong choice: nobody on the buyer side can describe last month's output, estimates are never updated, and the vendor team keeps expanding without an obvious reason.

Retainer

A retainer books a set amount of capacity every month, typically a stable team or a fixed block of hours. It suits continuing needs like caring for a live product, handling a steady flow of smaller improvements, or keeping senior expertise within reach.

Its strength is continuity. The same people come to understand the product, the business and the users, and that understanding builds over time. Its weakness is waste. If nobody manages the queue of work, the buyer pays for idle capacity and the arrangement starts to feel like a forgotten subscription.

Signals it was the wrong choice: hours go unused month after month, the work is really one big project wearing a different label, or the buyer keeps expecting guaranteed deliverables that a retainer was never meant to provide.

Three Questions I Ask First

How well do we understand the work? If acceptance criteria can be written for everything today, fixed price might fit. If learning along the way is expected, time and materials is the more honest choice.

Who should absorb the cost of change? Fixed price places it on the vendor, who will price it in. Time and materials places it on the buyer, which is only fair when the buyer truly controls priorities.

Is this a project or an ongoing relationship? Projects end. A product that needs attention for years is better served by a retainer and a consistent team.

Plenty of strong engagements mix models: a short fixed price discovery to define scope, time and materials for the build, then a retainer for support. The goal is not to be loyal to one structure. It is to fit the contract to the level of uncertainty.

The Part No Contract Can Fix

No structure rescues a relationship that is already broken. The best engagements I have been part of had the same habits no matter how they were billed: a written definition of done, a simple way to handle change, frequent demos of real software and a willingness on both sides to share bad news early.

Choose the model that fits the work. Then invest in those habits, because that is where software projects are really won or lost.

I took a firm from $6M to $60M in under three years.