Fixed-Price vs T&M: Which Contract Type Costs You More

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: A UK-based pre-Series A SaaS founder commissioning their first external build, holding two proposals — one fixed-price, one T&M — and trying to decide which contract structure protects their runway without handing the vendor a blank cheque

If you're staring at two proposals for your first MVP build — one fixed-price, one time-and-materials — the honest answer is this: fixed-price is usually cheaper only if your requirements are genuinely stable, which for a pre-Series A SaaS they almost never are. The headline number on a fixed bid is not the price you will pay. It is the price you will pay before the first change order. The clause that decides your actual spend is not the fee schedule — it is the change-control definition buried in the SOW appendix, and it is the one most founders skim.

Below is how to read both documents the way a procurement lead would, which clauses to rewrite before signing, and the question to put to each vendor. This is not legal advice — have a solicitor who handles tech contracts review the final draft. But by the time it reaches them, you should already know which structure fits your risk profile and which words are doing the real work.

Why the fixed-price quote looks cheaper than it is

The McKinsey-Oxford study of 5,400 large IT projects found software projects run an average of 66% over budget — the highest overrun of any project category — and deliver 56% less value than predicted. One in six becomes a 'black swan' with overruns of 200–400% — enough to threaten the organisation itself. That is the base rate your contract is trying to beat.

Here is what a vendor pricing a fixed bid actually does. They take the SOW, estimate internal hours, add a risk premium of 20–40% to cover the ambiguity, and quote you the total. If you push back on the number, they do not reduce the risk — they tighten the SOW. Anything not explicitly listed becomes a variation, billable at a day rate that was never on the first page of the proposal. Gartner data cited by ContractKen shows the average IT project runs 25–50 change requests a year, and roughly 80% of outsourcing contracts have a formal change-control procedure precisely because vendors know this is where the margin lives.

So the real comparison is not £X fixed vs £Y per day. It is:

• Fixed-price total = headline fee + (expected change orders × variation rate) + whatever you pay to resolve disputes about what 'in scope' meant
• T&M total = day rate × actual days used, with no premium for ambiguity but no ceiling either

Which is bigger depends almost entirely on how stable your requirements are on day one. PMI found 37% of organisations cite inaccurate requirements as the primary cause of project failure — the single largest one. If you are commissioning your first external build for a product that has not yet found its market, your requirements are, by definition, not stable.

When fixed-price actually wins

Fixed-price is the right structure when three conditions hold at once:

1. The scope is genuinely bounded and well-understood. You are rebuilding a known system, integrating a documented API, or shipping a feature set a competitor already has. There is a reference implementation.
2. You do not expect to learn anything that would change the spec mid-build. No user testing that could redirect flows. No regulatory ambiguity. No pending design decisions.
3. You value budget predictability more than product-market fit optionality. You are reporting to a board that wants a number, not a learning cycle.

This describes a compliance rebuild, a white-label deployment, or a migration — not a first MVP. For an MVP where you are deliberately shipping to learn, the fixed-price structure penalises exactly the behaviour you want: changing your mind based on what users tell you.

When T&M actually wins

T&M fits when you accept you will make scope decisions during the build, and you want the pricing structure to reflect that. The tradeoff is honest: you take on cost uncertainty in exchange for product flexibility. T&M is bad at reassuring a non-technical board, bad at protecting you from a slow vendor, and bad when you do not have anyone internally who can read sprint output and tell you whether the burn rate is justified.

If you cannot staff a product owner who meets the vendor weekly and signs off scope decisions, do not sign T&M. You will discover six weeks in that velocity is low, scope has drifted, and you have no mechanism to course-correct. The structure assumes an active, technically literate client. Fixed-price assumes a passive one — which is why vendors often prefer it for first-time buyers.

The hybrid most mature vendors will offer if you ask

A capped T&M arrangement — sometimes called 'T&M with not-to-exceed' — bills by day rate but caps total spend at a ceiling, with a mechanism for either party to pause or renegotiate at an agreed threshold (say 75% of cap). This gives you:

• A ceiling your board can underwrite
• Flexibility to change scope inside the ceiling without a change order for every tweak
• A natural review point before the money runs out

The vendor still prices the cap with a risk premium — smaller than fixed-price, bigger than open T&M — but you avoid the per-change-order grind. Ask for this if neither proposal on your desk mentions it.

The clauses that decide your actual spend

These are the ones to read line-by-line before signing either contract type. A UK IT outsourcing practice guide on Lexology notes that the two most common disputes are scope ('what is in scope of the agreement?') and charges ('calculation of unit charges and the cost of change'). Both live in the clauses below.

1. The scope / SOW appendix

What it does: defines what the vendor has agreed to deliver. Everything else is a variation.

Wording that protects you: scope is defined by user outcomes and acceptance criteria, not feature lists. For example: 'A registered user can complete KYC verification end-to-end within 5 minutes, with pass/fail outcome logged and queryable.' This absorbs minor UI and flow changes without triggering a change order.

Wording that quietly does not: scope defined as 'the features listed in Appendix A' where Appendix A is a bullet list of nouns ('login screen, dashboard, admin panel'). Any field, state, or edge case not enumerated is out of scope and billable.

Question to ask the vendor: 'If a user test in week six shows our onboarding flow needs three extra screens, is that a change order under this SOW, and if so, how is it priced?'

2. The change-control clause

What it does: defines the process and price for anything outside the SOW.

Wording that protects you: change requests under a defined threshold (e.g. half a day of effort) are absorbed into sprint capacity at no extra cost. Larger changes require a written variation with a quoted price and a right of refusal — you can say no and the project continues without that change. A monthly cap on cumulative variations exists.

Wording that quietly does not: 'all changes to the Scope will be documented in a Change Request Form and priced at the Supplier's standard rates.' No threshold, no cap, no refusal right. Every clarification becomes a mini-negotiation and the vendor controls the price.

Question to ask: 'Show me the three most recent change orders you have raised on comparable projects, with the trigger and the price.' A vendor who will not share redacted examples is telling you something.

3. Acceptance criteria and payment milestones

What it does: defines when you have to pay, and what the vendor has to show to earn each payment.

Wording that protects you: milestones tied to demonstrable outcomes you can test — 'User can create account, log in, and complete first transaction in staging environment, verified by Client within 10 business days.' Payment released on acceptance, not on delivery. A defined window for raising defects.

Wording that quietly does not: milestones tied to vendor-internal activities — 'completion of development sprint 3' — with payment due on invoice. You pay whether or not the sprint produced working software, and you have no leverage to insist on fixes.

Question to ask: 'What specifically do I test, and in which environment, before I release milestone payment 2?'

4. The warranty and defect-fix window

What it does: defines who pays to fix bugs found after launch.

Wording that protects you: a warranty period (typically 60–90 days post-acceptance) during which defects — code that does not meet the agreed acceptance criteria — are fixed at no cost. The clause distinguishes defects (vendor's cost) from change requests (your cost) using the acceptance criteria as the test.

Wording that quietly does not: warranty applies only to 'reproducible critical defects' as determined by the Supplier. The vendor is judge and jury on whether your bug qualifies.

5. IP assignment and the escrow question

What it does: determines whether you own the code when the engagement ends.

Wording that protects you: all foreground IP (code, designs, documentation, data models, trained model weights if AI is involved) assigns to you on payment of each milestone — not on final payment. Background IP (vendor's pre-existing libraries) is licensed to you perpetually and irrevocably for the purpose of operating the software. Source code is in a repository you control from day one.

Wording that quietly does not: IP assigns 'on completion of the Services and payment in full of all Charges.' If there is a dispute, you do not own the code during it. Vendor retains repository control.

On escrow: for a pre-Series A build, source code escrow is overkill if you already have repository access and your own cloud account. It matters when the vendor also hosts production on infrastructure you cannot access.

6. Termination and transition-out

What it does: defines how you leave if things go wrong.

Wording that protects you: termination for convenience with 30 days' notice, pro-rated payment for work-in-progress only. Mandatory transition assistance for a defined period (e.g. 20 person-days) at agreed rates, including handover documentation, access transfer, and up to two weeks of answering questions from the incoming team.

Wording that quietly does not: termination only for material breach, with no obligation to assist transition. You can leave but you cannot take anything useful with you.

How this maps to the two proposals on your desk

Lay both proposals side-by-side and score them on the six clauses above, not on the headline price. A fixed-price proposal with weak scope definition and strong vendor-favouring change control is more expensive than a T&M proposal with capped spend and a defined review cadence — even if the fixed number looks lower. PMI's data shows 52% of projects experience scope creep, and those projects run an average of 27% over budget. In a fixed-price contract, that 27% lands on you as change orders. In open T&M, it lands on you as extra days. In capped T&M, it forces a scope conversation before it lands anywhere.

An illustrative worked comparison

Consider two proposals for the same two-integration MVP with no legacy data to migrate, assumed scope of roughly four months. These are illustrative shapes, not quotes.

• Fixed-price proposal quotes a flat fee with a 25% variation rate on the headline. If the project runs the PMI-average 27% over budget via scope creep (which, remember, is the average not the worst case), your actual spend is 1.27× the headline — plus the 15% uplift McKinsey-Oxford attributes to each additional year of duration if slippage pushes you long.
• T&M proposal at a day rate × estimated days, no premium baked in, but no ceiling. If you have a disciplined product owner and freeze scope for sprints, you may land below the fixed-price headline. If you do not, you can easily exceed the fixed-price-plus-variations total.

The variables that would turn either shape into a real number are: how clearly your acceptance criteria are written on day one, how many integrations are in-scope and whether their APIs are documented, whether you have an internal product owner available weekly, and whether the vendor's variation rate is capped. Those are the specifics worth working through with a vendor before signing anything.

How CodeNicely can help

We have been on both sides of this conversation. The engagement most relevant to a UK pre-Series A founder deciding contract structure is GimBooks — a YC-backed fintech where the scope evolved substantially between the initial brief and what shipped, because real users told the founder things the spec did not anticipate. A rigid fixed-price structure would have either locked in the wrong product or generated a wall of change orders. We ran it as a staged engagement with capped sprint budgets and defined review gates, which is the structure we recommend to most first-time founders building something genuinely new.

If you want a second read on the two proposals on your desk — not to pitch a third, but to help you ask the right questions of the two you have — we do that for founders at your stage. The IP assignment, repository ownership, and transition-out clauses are the ones we see most often get a founder in trouble 18 months later when they switch suppliers or raise their Series A and due diligence starts.

The decision, in one paragraph

If your requirements are genuinely stable and you have no appetite for mid-build learning, take the fixed-price proposal and spend an afternoon rewriting the change-control clause with your solicitor. If your requirements are not stable — which is the honest answer for most first MVPs — ask both vendors for a capped T&M structure with a defined review gate at 75% of cap, strong acceptance criteria, and IP assignment on each milestone. The headline number matters less than the mechanism for handling the inevitable 25–50 change requests the Gartner data says are coming.

This article is general guidance, not legal advice. Have a solicitor experienced in UK tech contracts review the final document before signing — the cost of an hour of their time is trivial compared to the cost of the clauses discussed above going the wrong way.

Frequently Asked Questions

Is fixed-price or T&M cheaper for an MVP?

Fixed-price is cheaper only if your scope does not change during the build. For a first MVP where you expect to learn from users and adjust, the change-order revenue a fixed-price vendor earns typically pushes total spend above a well-managed T&M engagement. PMI data suggests over half of projects experience scope creep averaging 27% over budget — in a fixed-price contract that lands on you as variations.

What is the biggest risk in a fixed-price software contract?

The change-control clause. If scope is defined as a feature list rather than user outcomes, and variations are priced at the vendor's standard rates with no cap or refusal right, every clarification becomes a billable negotiation. UK outsourcing dispute data from Lexology confirms scope and charges are the two most common sources of litigation.

What is capped T&M and should I ask for it?

Capped T&M bills by day rate but with a not-to-exceed ceiling and a defined review gate (typically 75% of cap). It gives you a budget your board can underwrite without the per-change-order friction of fixed-price. Most mature vendors will offer this if asked — it is often the right structure for a first external build.

How do I know if the fixed-price quote has enough risk premium baked in?

You usually cannot — but you can ask the vendor to show you the three most recent change orders they raised on comparable projects, with the trigger and the price. If the change-order volume is high, their fixed-price risk premium is probably low and you will pay the difference in variations. If they will not share redacted examples, treat that as a data point.

What drives the budget range for an MVP build and what would turn it into a real number?

The main drivers are: number and complexity of third-party integrations, whether the data model is novel or follows a known pattern, regulatory scope (KYC, health data, payments), and whether you have an internal product owner available weekly. The variables that convert a range into a quote are scoped acceptance criteria, a documented integration list, and a decision on hosting and compliance posture. Those are what to work through in a scoping conversation before any vendor commits to a number.