Fixed price or time and materials?

Start with who carries the risk

Read any engagement model this way and the rest follows. In fixed price, the supplier absorbs the cost of an underestimate — so the quote necessarily includes a premium for the things neither side can foresee. In time and materials, you absorb it, and you pay for the hours actually worked.

Neither is generous or exploitative. They are different distributions of the same uncertainty, and the correct choice depends on how much uncertainty there is.

Both models also assume the build is happening. If you have not yet tested that assumption — whether a licensed product would cover the process for a fraction of the cost — the build-or-buy test we apply is the decision that belongs before any contract conversation. A model chosen well for software you should not have written is still the wrong model.

Scroll the table sideways to compare all three.

The sprint cap removes the usual objection

The standard objection to time and materials is that it feels open-ended. A per-sprint spend cap fixes that without giving up the flexibility: you agree a ceiling per two-week cycle, we work to it, and if something would exceed it you hear about it before the work happens rather than on the invoice.

Most of our time-and-materials clients use one. It converts an unbounded commitment into a series of small, bounded ones, and it means the decision to continue is taken every fortnight with a working demo in front of you.

Three times we say the model you asked for is wrong

1. Fixed price on a genuine unknown

"We want a fixed price for an AI assistant" — before anyone has measured whether the accuracy is reachable. A fixed price on an unknown forces both sides to pad: we price the worst case, you pay for risk that may not exist, and every subsequent conversation becomes a scope argument.

What we propose instead: a fixed-price discovery or evaluation phase, then a fixed price on the part that is now known. You get certainty where certainty is possible, and the specification is yours to take elsewhere if you prefer. The worked example is the two-week AI evaluation set out in RAG or fine-tuning — a test set of real questions in week one, a deliberately ugly prototype against real data in week two, and measured accuracy, cost per call and latency at the end of it. Roughly one project in five stops there, which is the cheapest outcome available to either side.

2. Time and materials with nobody steering

The model works when someone on your side owns the backlog and attends the demos. Without that, we are guessing at priorities and you are paying for the guesses. It is the arrangement most likely to end with a client feeling they spent a lot and received something they did not want.

What we propose instead: fixed scope for a first release so there is a defined target, then time and materials once your product owner is in place.

3. A dedicated team for a short, defined project

A dedicated squad takes three to four weeks to assemble and onboard before it is productive — that is the cost of selecting the right people rather than the first available ones. For a project with a clear end date, that is overhead you pay for and never recover.

What we propose instead: fixed scope or time and materials now, and the dedicated-team conversation when the roadmap becomes continuous rather than a project.

What is the same whichever you pick

• Full IP assignment on payment — repository, infrastructure, credentials and documentation. No retained licence, no proprietary framework you would have to keep paying for.
• You keep everything built and paid for if the engagement ends early, whatever the reason. There is no clause that makes stopping expensive.
• Discovery output is yours regardless. Taking the specification to another supplier is a legitimate outcome, and discovery is priced on that basis rather than as a loss leader.
• A 30-day post-launch defect window at no charge for defects traceable to our build.
• Thirty days' notice, either direction, with a documented handover.

The question that decides it

How well do you know the requirement? If it is written down and stable, fixed price and buy the certainty. If you are still discovering it — most first products, most AI work, most legacy modernisation — time and materials with a cap will cost less and argue less.

If you are unsure which describes you, that is itself the answer: you are in discovery, and the honest first step is a short paid phase that produces the specification a fixed price could then be built on.

Whichever model you land on, it wraps a number it does not set. Scope, integrations and the operational surface around the product decide the figure long before the contract shape does — the four decisions that drive the cost of a SaaS MVP works through the ones that move it most, and they are worth settling before anyone argues about which model to buy them under.

The full comparison of all four models, including white-label, is on engagement models. If the need is ongoing capacity rather than a project, dedicated teams and AMC support covers rates and onboarding. Agencies reselling delivery should start at white-label partnership instead. Other guides are collected on the insights index.

Questions

Premiums, caps and change requests

Where does the fixed-price premium actually go?

Into contingency against the parts of the specification nobody has tested yet — the integration whose sandbox behaves differently from its documentation, the migration whose source data is worse than described. We put that contingency in the estimate as a named line rather than folding it into the day rate, so you can see what the certainty is costing and decide whether it is worth buying. A specification we wrote ourselves during discovery carries a smaller one than a document handed to us, because we already know what is in it. Unspent contingency is not refunded — that is what fixed price means. A supplier promising to hand it back is quoting time and materials with more paperwork.

How does the sprint spend cap work in practice?

You agree a ceiling for each two-week cycle, expressed in engineer-days rather than a currency figure so it survives an exchange-rate move. We plan the sprint to fit inside it. If a story turns out larger than estimated, you hear that when we know it rather than on the invoice — either something leaves the sprint, or you approve the extra in writing before the work happens. The cap is a ceiling, not a budget: a sprint that lands under it bills the hours actually worked, and nothing rolls forward into the next one. You can also change it between sprints, because it is a planning number rather than a contract term either side has to renegotiate.

Can both models run on one project at the same time?

Yes, and it is often a better answer than switching from one to the other halfway. The usual shape is fixed price on the half that is genuinely known — authentication, billing, the data migration — and time and materials on the half you are still working out, both under one statement of work with a single demo every fortnight. The risk is an argument about which side of the line a piece of work falls on, so we write the seam down: the fixed-price scope is enumerated item by item, and anything not named in it is time and materials by default. That default is deliberate — ambiguity resolves towards the model you can stop at a sprint boundary rather than the one you cannot.

Under time and materials, what stops the work expanding to fill the budget?

Nothing structural does, and treat anyone claiming otherwise carefully — on time and materials we are paid the same whether a story takes its estimate or twice it. What protects you is visibility rather than a promise. Every story carries an estimate in engineer-days agreed at sprint planning, the demo at the end of the fortnight shows working software against those stories, and we report the variance between estimated and actual each time. A team drifting past its own numbers is therefore visible to you within a fortnight rather than a quarter, and if the variance keeps running one way we raise it before you have to. A supplier whose every report says "on plan" is not measuring.

What does a change request cost, and how is it priced?

The engineers who would do the work estimate it in engineer-days, at the rate already written into the statement of work. There is no change-request fee and no premium rate for changes — pricing changes above the original scope is what turns a fixed-price project adversarial by month three. You get the estimate, the schedule impact and what it displaces, in writing, before anything is built. Where a change is small enough that estimating it would cost more than doing it, we absorb it and tell you that we have.

Is discovery refundable, and can we take it elsewhere?

It is not refundable, and be wary of anyone offering that — discovery that only pays for itself if you buy the build is a sales cost wearing a deliverable's clothes, and it shows in what gets recommended. It is entirely reusable. What you receive is a written specification, an architecture, an estimate broken down by workflow and the risks we found, and it is yours to take to another supplier or to shelve for a year. Some discovery phases end with us recommending that you do not build the thing at all.

Published: 23 August 2026 Last updated: 2 September 2026 Written by Canopus delivery team