Fixed Price, T&M or Retainer: Choosing Your Model

The engagement model decides who carries the risk. Most buyers pick one before they know what the risk is.

That ordering is backwards, and it explains a lot of soured vendor relationships that get blamed on everything else. The model is not a procurement formality; it is the contract's answer to the only question that matters when reality diverges from the plan: who absorbs the difference?

What each model is

Three models cover almost every custom software engagement. Strip away the terminology and each is a different answer to three questions: how certain is the scope, how do changes get handled, and who absorbs an overrun.

Model: Fixed price

Scope certainty required: High: scope is defined and agreed before work starts

How changes are handled: Formal change requests, each renegotiated against the agreed scope

Who absorbs overrun: Vendor absorbs effort overrun inside scope; client pays for every change outside it

Model: Time and material (T&M)

Scope certainty required: Low: direction is clear, destination is still being discovered

How changes are handled: Reprioritise the backlog at any time, no renegotiation ceremony

Who absorbs overrun: Client absorbs effort overrun; vendor commits people and transparency

Model: Retainer

Scope certainty required: None fixed: a stream of work rather than a defined project

How changes are handled: A running priority queue, reviewed on a regular rhythm

Who absorbs overrun: Shared: client carries utilisation of the reserved capacity, vendor guarantees availability

Notice there is no column for which model is cheapest. That column does not exist. Each model prices the same uncertainty differently, which is why choosing by model alone, before understanding your project's uncertainty, is choosing blind.

Fixed price: when scope is truly known

Fixed price works beautifully under one condition that is rarer than buyers think: the scope is truly known. Not "we have a requirements document", truly known. The workflows are mapped, the integrations are identified, the edge cases have been walked, and nobody expects to learn anything important during the build.

When that condition holds, fixed price is the right call. The vendor carries the estimation risk, you get budget certainty, and the formality of change requests protects both sides from drift.

When it does not hold, fixed price turns adversarial on a schedule you can predict. Every discovery during the build becomes a change request. Every change request becomes a negotiation. The vendor, carrying the overrun risk, is structurally pushed to interpret scope narrowly and to resist improvements that any sane engineer would otherwise just make. You end up with the system that was specified, which is not the same as the system you need, and both sides have the paperwork to prove they behaved correctly. A fixed-price contract on an unknown scope does not remove the uncertainty; it just decides, in advance, that you will argue about it.

The honest test: if your team cannot describe what "done" looks like in detail today, the scope is not fixed, whatever the document says.

T&M: when discovery is honest

Time and material has a reputation problem because it is the model most abused by vendors who bill hours into fog. Used honestly, it is the right model for exactly one situation: the destination is still being discovered, and everyone admits it.

Discovery is not a delay. We keep repeating this because buyers keep treating the discovery phase as vendor foot-dragging before the real work. It is the real work. The weeks spent mapping workflows, interrogating edge cases and finding the integration landmines are what make every later week cheaper. T&M is the natural home for that phase, because fixing a price on work whose purpose is to find out what the work is would be fiction with a signature on it.

The protection in a T&M engagement is not the contract, it is the transparency rhythm. Working software on a regular demo cadence, a backlog you can see and reorder, effort visible as it is spent. If a vendor offers T&M without that rhythm, the model is not your problem, the vendor is. How we run this rhythm is laid out at accucia.com/how-we-work, and the commitments that sit underneath it, on ownership, continuity and conduct, are published on our trust page.

One operator aside: T&M also changes your job as the client. You are no longer buying an outcome at a distance; you are steering. Buyers who show up to the demos and make the priority calls get excellent results from T&M. Buyers who disappear for a quarter should not choose it.

Retainer: when the system lives and grows

Launch is not the end of the engagement question; it is where the question changes shape. A live system generates a continuous stream of small work: fixes, adjustments, enhancements, platform updates, the occasional urgent thing on a Friday. None of it is a project. All of it matters.

A retainer fits this phase because it reserves capacity rather than scoping deliverables. A block of team attention is yours each month, pointed at a priority queue you control. No per-request negotiation, no re-onboarding a stranger to your codebase for every small change, and the people doing the work accumulate knowledge of your system instead of starting cold.

This is also the year-three answer. Systems rot when nobody is accountable for their continuity; a retainer makes continuity someone's explicit job. The trade is utilisation risk: in a quiet month, the reserved capacity is yours whether you filled the queue or not. Operators who run retainers well treat the queue as a standing asset, there is always a next improvement worth making on a system the business depends on.

How the retainer compares with warranty, AMC and per-request support for the post-launch phase specifically is covered in our guide to choosing the right software maintenance and support model.

Mixing models across a project's life

The cleanest engagements we run use different models for different phases, because the uncertainty profile changes as the project ages.

A common arc: discovery on T&M, because its purpose is to reduce uncertainty and you cannot fix a price on the unknown. Then, if discovery has done its job, the build can move to fixed price or milestone-based fixed price, because now the scope genuinely is known and the vendor can carry estimation risk honestly. After launch, a retainer takes over, because the work becomes a stream rather than a project.

Each transition reprices the risk to match reality. Scope risk sits with the vendor exactly when the vendor has enough information to own it. Flexibility exists exactly when you need it. Continuity is guaranteed exactly when the system starts to live.

The arc is not a law. Some projects stay T&M end to end because the business is changing under them; some post-launch phases are quiet enough for per-request support. The principle travels even where the specific sequence does not: match the model to the phase's uncertainty, and renegotiate the model when the phase changes rather than stretching one agreement across situations it was never shaped for.

Accucia's view

Engagement models are risk instruments, and the mistake buyers make is choosing one by habit or by procurement template before asking what the actual risk is. Fixed price for scope that is truly known. T&M for honest discovery, protected by a transparency rhythm, not by hope. A retainer once the system lives and continuity becomes the risk. We run all three at Accucia, usually across the life of a single project, and we will tell a prospect plainly when the model they arrived with does not fit the uncertainty they are carrying. A vendor who will not have that conversation at signing will have it with you later, at a worse moment.

Not sure which model fits the project in front of you? Message us on WhatsApp at https://wa.link/1bwdd2 and describe it in three sentences; we will give you a straight answer.

FAQ

What is the difference between fixed price and time and material?

Fixed price agrees scope before work starts: the vendor absorbs effort overrun inside that scope, and every change outside it is renegotiated. Time and material keeps scope flexible: you reprioritise freely and the client absorbs overrun, protected by a transparency rhythm of demos and visible effort rather than by a scope document.

When is a fixed price contract right for software development?

When scope is truly known: workflows mapped, integrations identified, edge cases walked, and nobody expects major learning during the build. Under genuine certainty, fixed price gives budget predictability and puts estimation risk on the vendor. On uncertain scope, it produces change-request battles instead of working software.

What is a retainer model in software development?

A retainer reserves a block of team capacity each month, pointed at a priority queue the client controls. It fits live systems that generate continuous small work: fixes, enhancements, platform updates. The vendor guarantees availability and accumulated system knowledge; the client carries utilisation of the reserved capacity.

Can you combine engagement models in one project?

Yes, and mature engagements usually do. A common arc runs discovery on time and material, moves the build to fixed price once scope is genuinely known, then shifts to a retainer after launch when work becomes a continuous stream. Each transition reprices risk to match the phase's uncertainty.