Few decisions shape a software project as quietly as the contract model. Teams argue for weeks about the tech stack and then sign whatever engagement structure the vendor put in the proposal. Months later, when the relationship is strained, the root cause is often sitting in that contract: the wrong model for the kind of work being done.

I have been on both sides of this conversation, first as a partner growing a software consulting company from about $6M to $60M in under three years, and later as the founder of a fully remote consultancy. Here is how I think about the three common options, and the warning signs that you picked the wrong one.

Fixed Price: Great for Known Work, Risky for Everything Else

A fixed price contract promises a defined result for a defined fee. Buyers like it because the budget feels safe. Vendors accept it because it can be profitable when the work is well understood.

It works best when the scope is genuinely clear: a small, well specified build, a migration with known boundaries, or a feature set the vendor has delivered many times before.

The problem is that most software is not like that. When requirements are still forming, a fixed price forces both sides to pretend they know more than they do. The vendor pads the estimate to cover risk, so the buyer overpays for certainty. Or the vendor underbids to win, and every change becomes a negotiation.

Warning signs you picked wrong: change requests are piling up faster than features, every meeting turns into a debate about what was "in scope," and the vendor is quietly cutting corners on testing to protect its margin.

Time and Materials: Flexible, but Only With Discipline

Under time and materials, the buyer pays for the hours and skills actually used. It suits work where the destination is clear but the route is not: new products, discovery heavy builds, integrations with messy legacy systems.

The flexibility is real. Priorities can change week to week without renegotiating the contract. The catch is that the risk moves to the buyer. Without strong visibility, hours can drift and nobody notices until the invoice arrives.

Time and materials works when three things are in place: a clear backlog the buyer actively prioritizes, regular demos of working software, and honest burn reports that compare spend with progress.

Warning signs you picked wrong: the buyer cannot say what was delivered last month, estimates are never revisited, and the vendor's team keeps growing without a clear reason.

Retainer: Built for Ongoing Partnership

A retainer reserves a set amount of capacity each month, usually a fixed team or a fixed number of hours. It fits ongoing needs: maintaining and improving a live product, a steady stream of small enhancements, or access to senior expertise on demand.

The value is continuity. The same people learn the product, the business and the users, and that knowledge compounds. The risk is underuse. If nobody owns the queue of work, the buyer pays for capacity that sits idle, and the relationship starts to feel like a subscription nobody remembers signing up for.

Warning signs you picked wrong: hours go unused month after month, the work is really one large project in disguise, or the buyer keeps asking for fixed deliverables that a retainer was never designed to guarantee.

How to Choose

I ask buyers three questions before recommending a model.

How well do we understand the work? If you can write acceptance criteria for every piece today, fixed price may fit. If you expect to learn as you go, time and materials is more honest.

Who should carry the risk of change? Fixed price puts it on the vendor, and the vendor will charge for it. Time and materials puts it on the buyer, which is fair only if the buyer has real control over priorities.

Is this a project or a relationship? A project has an end. A product that needs care for years is better served by a retainer with a stable team.

Many good engagements combine models. A short fixed price discovery phase can define the scope, followed by time and materials for the build and a retainer for ongoing support. The point is not loyalty to a model. It is matching the contract to the uncertainty.

What Matters More Than the Model

No contract structure fixes a broken relationship. The best engagements I have seen shared the same habits regardless of the model: a written definition of done, a simple process for handling changes, frequent demos of real software, and both sides willing to raise bad news early.

Pick the model that fits the work. Then put your energy into the habits, because that is where projects are actually won or lost.

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

If you are planning a software project and want an honest view on how to structure it, visit https://tdzpro.com.

Ashkan Rajaee is the founder of TDZ Pro. As a partner, he helped grow a software consulting company from about $6M to $60M in under three years, and he founded and scaled a fully remote software consultancy.