Fixed price or time and materials?
Every engagement model transfers risk somewhere. Fixed price moves it to the supplier and you pay a premium for that. Time and materials moves it to you and costs less on average. Anyone presenting one as strictly better is selling the one that suits them.
Choose by how well the requirement is known, not by project size. A written, stable specification suits fixed price and buys you certainty at a premium. A requirement you are still discovering suits time and materials with a per-sprint cap, which costs less on average and lets you reprioritise without a change request.
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.
| Fixed price | Time & materials | Dedicated team | |
|---|---|---|---|
| Risk sits with | The supplier | You | You |
| Best when | The specification is written and stable | Requirements will evolve as you learn | The roadmap is continuous, not a project |
| Scope changes | Change request, priced before work | Reprioritise freely each sprint | Reprioritise freely each sprint |
| Cost predictability | Exact, agreed upfront | Monthly, with a sprint cap if you want one | Fixed monthly per engineer |
| Average total cost | Higher — includes a risk premium | Lower on average | Lowest per engineer-month |
| Speed to start | Slower — needs discovery first | Fast, can start on a rough brief | Three to four weeks to assemble |
| What you must supply | A settled specification | Someone who owns the backlog | Your own technical leadership |
| Notice to stop | End of current milestone | 30 days | 30 days |
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.
Two-week sprints ending in working software are not a process preference. They are what makes either model safe — slippage surfaces within a fortnight rather than at a deadline, and with time and materials you can stop at any sprint boundary having kept everything built so far.
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.
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.
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.
Related reading
Tell us how well you know the requirement.
That single answer picks the model. An engineer replies within one business day with a recommendation and the reasoning — including when it is the model you did not ask for.
- Email — contact@canopussoft.com
- Phone / WhatsApp — +91 817 979 7732