Fixed-Price vs Time-and-Materials: Which One Is Working Against You?

Two quotes land in your inbox for the same project. One says “$60K, fixed, done in twelve weeks.” The other says “$150 an hour, roughly 400 hours, we’ll bill as we go.” Most founders read the first one and feel relief. A single number, a date, no surprises. They read the second one and feel nervous, because it’s open-ended and they can already picture the meter running.

That instinct is backwards more often than it’s right.

The pricing model isn’t an accounting detail you sort out at the end. It’s the thing that decides whose interests the team is protecting when the project gets hard, and every project gets hard. Before anyone writes a line of code, the contract has already quietly picked a side. Almost no founder thinks about this, and it’s one of the most expensive things to get wrong.

We’ve taken over four builds that stalled with an agency, and in every single one the pricing model was pulling the team away from the founder long before anyone noticed. Nobody set out to behave badly. The contract just made the wrong thing the profitable thing.

What Fixed-Price Actually Does to Their Behaviour

Fixed-price sounds like the vendor is taking on the risk. You agree a number, and if it costs them more, that’s their problem. In theory.

In practice, they know that too, so they price the risk in before you sign. A competent shop looks at your brief, estimates the work, then adds a buffer for everything that might go wrong. You don’t see the buffer. You just see a number that’s higher than the honest cost of the work, because you’re paying for surprises that may never happen. That’s not a scam. It’s the only rational way to quote fixed on something uncertain.

Then the build starts, and the incentives get worse. Once the price is locked, every hour they spend is a cost to them. So three things start happening, none of which they’ll tell you about.

Every change becomes a fight. The moment you say “actually, can it also do this,” the answer is “that’s out of scope.” It has to be. Their margin lives inside the original spec, so anything outside it is either a change order billed on top, usually at a worse rate because you have no leverage mid-project, or a polite no. The model turns your natural learning into a negotiation.

Corners get cut where you can’t see them. As the deadline approaches and their margin tightens, something has to give. It’s never the demo, because you’d notice. It’s the invisible work: testing, documentation, the architecture decisions that don’t show up until month four. Fixed-price rewards the team for doing the least that passes your inspection, and you are not equipped to inspect the parts that matter most. When we open the codebase on a rescue, this is almost always where the damage is: the demo looked fine, the foundations underneath it were skipped to protect a fixed margin.

The spec becomes a weapon instead of a plan. Whatever got written down before anyone understood the problem is now the thing you’re both held to. You’re locked to your least-informed decisions, made on day zero.

None of this means fixed-price is a trap. It means fixed-price only works honestly under one condition: the scope is genuinely locked, well understood by both sides, and unlikely to move. A marketing site with a known page count. A defined integration with clear inputs and outputs. Redesigning a checkout flow that already exists. When the thing is truly knowable, fixed-price is great, and you should ask for it.

The problem is that founders reach for fixed-price precisely when scope is least knowable: a new product nobody has built before.

What Time-and-Materials Does Instead

Time-and-materials means you pay for the work actually done. Hourly or daily, billed as it happens. The risk of it taking longer sits with you, not the vendor.

Read that and your stomach tightens, because it sounds like an open cheque. Sometimes it is. But look at what it does to behaviour, because the incentives run the opposite way to fixed-price.

When there’s no fixed number to protect, there’s nothing to defend by fighting your changes. You want to adjust the flow after seeing it half-built? Fine, that’s just the next thing we work on. There’s no buffer being eaten, no margin to guard, no reason to say “out of scope.” The team can be honest with you, because honesty doesn’t cost them anything. T&M aligns everyone on the same job: figure out the right thing and build it well, together.

That’s exactly why it’s the right model when scope is unknown. A genuine MVP, an early product still finding its shape, anything where you’ll learn as you go and change your mind, and you should change your mind. T&M lets you.

But the honesty comes with a hole in the middle, and you have to see it clearly.

So T&M is honest but exposed. It rewards collaboration and truth-telling, and it removes the incentive to pad. It also removes the incentive to hurry, which is why it only works with two things in place: people you actually trust, and a ceiling written into the contract. Take either one away and the open cheque is real.

The Two Models, Side by Side

Neither model is good or evil. Each is a tool that fits a specific situation, and using the wrong one for your situation is what hurts you.

Notice the pattern. Fixed-price is predictable but adversarial. T&M is collaborative but open-ended. Each model’s biggest weakness is the exact thing the other one solves, which is why the smartest arrangements don’t pick a pure version of either.

The Middle Paths That Fix the Worst of Both

You don’t have to choose between “padded and adversarial” and “honest but bottomless.” The models most good technical partners actually run in the real world sit between the two, and they exist specifically to keep the honesty of T&M while capping the risk that scares you about it.

Capped time-and-materials, also called not-to-exceed. You bill for hours as they’re used, exactly like T&M, but the contract sets a ceiling the total can’t pass without your explicit sign-off. If the work comes in under, you pay less, which pure fixed-price never lets you do. If it’s heading over, that’s a conversation before it happens, not a bill after. You get the flexibility to change direction and a hard number you can take to your board. This is the single best default for most early-stage software.

Sprint or milestone billing tied to shipped software. You pay per sprint, usually two weeks, and each sprint ends with working software you can actually use, not a status report. The payment is tied to the thing existing, not to time elapsing. If it isn’t working, you can stop. That gives you natural exit points every fortnight and forces the “are we actually making progress” question into the open, on a schedule, instead of finding out at the end.

The thing that makes these work isn’t the billing mechanic on its own. It’s the mechanic plus visibility. A cap you can’t see progress against is just a slower surprise. Insist on both.

So Which One Should You Use?

Use fixed-price only when the scope is genuinely locked and both sides understand it: a known integration, a redesign of an existing flow, a page count that won’t move. Use capped time-and-materials for almost everything else, which is most MVPs and early products, since it keeps T&M’s honesty and adds fixed-price’s ceiling. Never run pure uncapped T&M with a team you don’t yet trust, and never take fixed-price on a scope you can’t actually pin down. Those two combinations reliably end in tears, one through drift, the other through padding and change-order warfare.

I run a company that builds this way, so weigh this accordingly: we work capped T&M with two-week shipping cycles, because it’s the model that keeps us on the same side of the table as the founder instead of quietly opposite them.

The people matter enormously. But good people inside a bad incentive structure still get pulled the wrong way, slowly, without anyone deciding to be dishonest. Pick the structure that lets good people stay good, and the rest of the relationship gets a lot easier to have.