Fixed-Price vs T&M vs Retainer: Which Contract to Choose?

Fixed price puts the risk of overruns on the vendor, time and materials (T&M) puts it on you, and a retainer buys a set block of senior capacity every month. The risk is real: in a study of 1,471 IT projects, one in six overran its budget by an average of 200%. Use fixed price for work you can specify on one page, T&M for exploratory work nobody can estimate honestly, and a retainer for ongoing work with a steady monthly budget.

Key takeaways

Every model prices risk. It just moves it. Fixed price is often more expensive per hour because the vendor builds in a buffer for the risk it carries.
Fixed price works only when scope is genuinely fixed. Short, well-defined engagements are where it shines. Large fixed-price projects mostly turn into change-request negotiations.
T&M is the honest choice when you can’t estimate the work. US federal procurement rules allow it only in that situation, and require a ceiling price.
Retainers buy availability and continuity, not a deliverable. Be explicit about hours, response times and what happens to unused hours.
Deposits of 25% or more are normal. A large deposit should come with a clear refund or exit clause.
Read guarantees for their mechanics: who decides whether the guarantee condition was met, by when, and what you keep if you walk away.

The three models at a glance

	Fixed price	Time & materials	Retainer
You pay for	A defined deliverable	Hours worked at agreed rates	Reserved capacity per month
Cost overrun risk	Vendor	You (unless capped)	Shared: fixed monthly spend, flexible output
Scope risk	You (anything not written down isn’t included)	Low (scope can change freely)	Low (priorities can change monthly)
Vendor incentive	Finish efficiently, minimise scope	Bill hours (in theory)	Keep you renewing
Best for	Small, well-specified work	Discovery, R&D, unclear requirements	Ongoing development, maintenance, advisory
Typical failure mode	Change-request battles, cut corners	Budget drift with no endpoint	Paying for hours nobody uses

Fixed price: how it works and who carries the risk

You agree a deliverable, a price and usually a deadline. The vendor absorbs any extra effort. The US Federal Acquisition Regulation puts it most clearly: a firm-fixed-price contract “places upon the contractor maximum risk and full responsibility for all costs and resulting profit or loss”.

That risk is not free. The UK government’s guidance for buying digital services, withdrawn at the end of 2025 but still a useful reference, said it plainly: “A fixed price approach can be more expensive because the supplier owns most of the risk.” A sensible vendor estimates the work, adds a buffer for unknowns, and quotes that. The less defined the scope, the bigger the buffer.

The deeper problem is scope. Martin Fowler argued two decades ago that when people say fixed price, “they mean fixing price, time, and scope”, and that software rarely allows a fixed-scope contract. His alternative still works: fix the budget and the date, then collaborate on the best set of features that fits. In practice that is “fixed price, variable scope”.

Where fixed price works well

Small, bounded engagements. One to four weeks of work with a written definition of done.
Repeatable work. Audits, migrations of a known shape, or a feature type the vendor has built many times. Estimation risk is low, so the buffer is small.
Productized offers. The vendor has standardised the scope and process, so the price reflects real effort rather than a guess plus padding.

Where it breaks

Large, novel projects. In their study of 1,471 IT projects, Flyvbjerg and Budzier found an average cost overrun of 27%. One in six projects was a “Black Swan”, with “a cost overrun of 200%, on average, and a schedule overrun of almost 70%”. A fixed-price contract on a project like that either bankrupts the vendor’s margin or becomes a dispute.
Discovery disguised as delivery. If the requirements document is full of “TBD” and “should be intuitive”, you are buying a guess.
Anything with heavy third-party dependencies. Vendor APIs, app-store review and data quality are all outside the contractor’s control.

Time and materials: how it works and who carries the risk

You pay for hours or days actually worked, at agreed rates, plus expenses. You can change direction whenever you like. You also carry the cost if the work takes longer than expected.

The FAR is blunt about when this model is appropriate. A T&M contract “may be used only when it is not possible at the time of placing the contract to estimate accurately the extent or duration of the work”. It also names the weakness: T&M “provides no positive profit incentive to the contractor for cost control or labor efficiency.” That is why federal T&M contracts must include “a ceiling price that the contractor exceeds at its own risk.”

The private-sector version is capped T&M. The UK guidance described it as the same as T&M “but there’s a limit on how much you have to pay”. If the cap is reached before the work is done, the supplier finishes at its own expense. If the work finishes early, you pay only for the time used. For most founders this is the best default for medium-sized, uncertain work.

What T&M costs in practice

Clutch’s review data, updated September 2026, puts the average software development project at $132,480, with a typical timeline of about 13 months. The most common budget band is $10,000–$49,999. Those long timelines are mostly T&M or milestone engagements. Without a cap or regular checkpoints, they are where budget drift lives.

For reference, the BLS puts the 2025 median pay for software developers, QA analysts and testers at $64.44 an hour. That is salary only. Agency rates also cover benefits, idle time, sales, management and margin, so expect a senior studio’s rate to be a multiple of it.

How to make T&M safe

Cap it. Use a total cap, or a cap per phase.
Bill in short cycles. Weekly or biweekly, with a timesheet you can actually read.
Demo every week or two. Working software is the only reliable progress report.
Keep a right to stop at any checkpoint without penalty beyond hours already worked.

Retainer: how it works and who carries the risk

A retainer is a recurring monthly fee for an agreed amount of work or access. Sprintlaw describes it as an arrangement where the client pays “an agreed fee upfront—usually monthly or periodically—for a guaranteed amount of work or access to your services”.

The word comes from law. Cornell’s Legal Information Institute distinguishes a general retainer, which pays for availability, from an advance-fee retainer, which is prepayment for future services. Software retainers mix both. You get a block of hours and the team’s attention: they know your codebase, sit in your Slack, and respond quickly.

Risk is shared. Your monthly spend is fixed, so there is no overrun, but output is not guaranteed in the way a fixed-price deliverable is. The main risk for you is paying for capacity you don’t use. The main risk for the vendor is being treated as an on-call team at a part-time price.

The rollover question

There is no universal rule for unused hours. Sprintlaw’s advice is the right one: decide whether hours “‘roll over’, are lost, or if the retainer simply buys access rather than hourly work. Make your policy explicit.” Common patterns include no rollover, rollover capped at one month, or rollover that expires after a quarter. Any of them is fine as long as it is written down.

When a retainer is the right answer

After launch. Maintenance, dependency upgrades, model migrations for AI features, and small features.
As a fractional senior team. Architecture decisions, code review and hard problems alongside an in-house junior team.
Steady, unpredictable work. You know there will be about 30 hours of work a month, but not which 30.

Deposits and payment schedules

Upfront payment protects the vendor from the most common freelance failure: not getting paid. A Freelancers Union survey of over five thousand freelancers found that 71% had struggled to collect payment at least once. The union’s own advice is to “ask for at least 25% upfront”.

Marketplaces solve the same problem with escrow. On Freelancer.com, milestone payments are held by the platform “until both parties agree to its release”.

In our view, these schedules are reasonable for each model:

Model	Reasonable schedule
Short fixed price (under 4 weeks)	50% upfront, 50% on delivery, ideally with an exit or refund clause tied to an early checkpoint
Longer fixed price	A deposit of 20–30%, then payments tied to milestones with clear acceptance criteria
T&M	Billed weekly, biweekly or monthly in arrears, sometimes with a small retainer-style deposit
Retainer	Monthly in advance

A 50% deposit is a lot of trust to extend to a vendor you have never worked with. It is fair when the engagement is short and a refund or stop clause limits your downside. Be wary of 50% or more upfront on a multi-month project with no checkpoint.

Guarantees and refund clauses in productized offers

Productized services (fixed scope, fixed price, fixed duration) increasingly come with guarantees. They come in three forms:

Checkpoint exit. You can stop at a defined point, such as a mid-engagement demo, and get some or all of your money back.
Outcome guarantee. A refund if a measurable result isn’t reached, for example a minimum cost saving.
Satisfaction guarantee. A refund if you aren’t satisfied, with no objective test. Talent marketplaces use versions of this. Toptal, for example, offers a trial period after which “If you’re not completely satisfied, you won’t be billed.”

For consumer advertising in the US, the FTC’s guides set the standard for these claims. A seller should only advertise a “Satisfaction Guarantee” or “Money Back Guarantee” if it will refund “the full purchase price” at the buyer’s request. Any material conditions must be disclosed “with such clarity and prominence as will be noticed and understood”. Those guides are written for consumer products, but they are a good test for any B2B guarantee too. If the conditions aren’t clear before you buy, the guarantee is marketing.

When you read a guarantee, check:

Who decides whether the condition was met. Is it you, the vendor, or an objective metric?
How it is measured. “30% savings” needs a baseline, a method and a workload.
The deadline for claiming it.
What you keep. Code, reports and findings produced before the refund.
What is excluded. Third-party costs, delays you caused, or changes in scope.

Our own offers use the first two forms. Our AI Feature Sprint lets you stop after the day-5 demo and get your deposit back. Our GPU Inference Speed Audit gives a full refund if we can’t find at least 30% savings. We designed them this way because a fixed price is only fair to the buyer if there is a cheap way out.

Which model fits your situation

Situation	Best fit	Why
A well-defined feature, audit or prototype in 1–4 weeks	Fixed price	Scope fits on a page; the risk buffer is small
A new product with fuzzy requirements	Paid discovery (fixed), then capped T&M or fixed-price phases	You can’t price what isn’t designed yet
R&D or performance work with uncertain outcomes	Capped T&M, or fixed price with an outcome guarantee	Nobody knows the answer in advance
Ongoing development after launch	Retainer	Continuity and context matter more than unit price
A large rebuild	Sequence of fixed-price phases or capped T&M, never a single big fixed bid	Large projects carry fat-tailed overrun risk
Staff augmentation inside your team	T&M	You direct the work, so you carry the risk

Mixing models is normal and often best. A common sequence is a fixed-price discovery or audit, then a fixed-price first version, then a retainer for iteration. Each step gives you a decision point. That fits the evidence on iterative delivery: in the Standish Group’s 2015 CHAOS data, “across all project sizes agile approaches resulted in more successful projects and less outright failures”.

Questions to ask before signing

For every model:

Who owns the code and IP, and when does ownership transfer: on signing, on each payment, or on final payment?
Who exactly is doing the work? Is it the senior people you met, or someone else?
How and when can either side end the contract, and what do I owe if I do?
Where does the code live during the engagement? Do I have repository access from day one?
What happens to my data, credentials and access when the engagement ends?

For fixed price:

What is the written definition of done, and who signs off on acceptance?
How are change requests priced and approved?
What happens if the deadline slips because of you, or because of us?
Is there a checkpoint where I can stop, and what do I get back?

For T&M:

Is there a cap, per phase or in total? What happens when we approach it?
How often will I see timesheets and working software?
What are the rates for each person, and can they change during the engagement?

For a retainer:

How many hours does the fee cover, and what happens to unused hours?
What response time can I expect for urgent issues?
How much notice is needed to scale up, scale down or cancel?

If a vendor can’t answer these clearly before you sign, the contract won’t answer them clearly either.

This article is general information, not legal advice. Have a lawyer review any contract before you sign it.

Where to start

If you have a well-defined piece of AI work, our AI Feature Sprint is a fixed $8,500 over 10 business days, with a day-5 exit and deposit refund. If you need ongoing senior capacity, our Senior Team Retainer is $6,000 a month for about 30 hours, or $9,500 a month for about 50 hours. Not sure which fits? Tell us about the work and we’ll suggest a model, even if it isn’t one of ours.