✦ Sales assets
Fixed price vs day rate: which one protects you
Fixed price vs day rate isn't about which is cheaper - it's about who carries the risk when requirements change, which they usually do. Get this wrong and the commercial model works against you, not for you.
Haystak · 11 August 2026 · Updated 11 August 2026 · 7 min read
Fixed price vs day rate is the first commercial decision in any software contract, and it decides who absorbs the cost when the scope shifts. A fixed price shifts that risk to the supplier, who prices it in upfront. A day rate shifts it to you, but usually at a lower headline cost if requirements stay stable.
Neither is inherently the safer choice - the right one depends on how well-defined your requirements are before the contract is signed, and how much change you genuinely expect along the way.
What each model actually means
| Fixed price | Day rate / time and materials | |
|---|---|---|
| Who carries the risk of scope creep | The supplier (priced into the fee upfront) | You (pay for the extra time it takes) |
| Cost certainty | High, provided scope doesn't change | Lower, unless carefully tracked |
| Best suited to | Well-defined, settled requirements | Evolving requirements, early-stage or exploratory work |
| Supplier's incentive | To minimise time spent, once the price is agreed | To keep working, unless well-managed |
| How change is handled | Formal change request, usually a fee | Simply more time billed |
Why fixed price isn't automatically 'safer'
A fixed price only protects you if the specification behind it is genuinely complete. If it's vague, the supplier will price in a margin for the uncertainty - meaning you're paying for risk either way, just without visibility into it. Worse, any gap in the spec becomes a change request at a price you didn't get to shop around for.
This is why a proper brief matters more under a fixed-price contract than a day-rate one. See how to write a software brief - the more complete it is, the more a fixed price genuinely reflects the work rather than a guess with a safety margin baked in.
Why day rate isn't automatically riskier
Day rate gets a bad reputation because of open-ended projects with no visibility into progress. Managed well - with a clear sprint plan, regular check-ins and a running total against a budget - it's often the more honest model, because you pay for what was actually built, not a margin for uncertainty nobody could price accurately anyway.
- Ask for weekly or sprint-based reporting against a plan, not just an invoice at the end of the month.
- Agree a not-to-exceed ceiling if cost certainty matters to you - this gets you day-rate flexibility with a fixed-price backstop.
- Check whether the supplier bills in day increments or hourly - hourly billing on ambiguous tasks is harder to audit.
Questions to ask before choosing
- 01How is a change to scope handled, and priced, under this contract?
- 02What happens if the project runs over - who pays the difference, and how is that decided?
- 03What reporting will I get during the project, and how often?
- 04Is there a cap or ceiling on a day-rate engagement, and can we agree one?
- 05What's excluded from the fixed price that I might assume is included?
How this connects to the rest of the contract
The pricing model is only one part of a contract worth reading carefully. Ownership of the finished code matters at least as much - see who owns the code - and neither question is answered by asking what does custom software cost in isolation from how that cost is structured.
If you're weighing up your first quote, our pricing page explains how we structure fixed and flexible work, and you're welcome to bring a quote you've already received to a call for a second opinion.
The Chartered Institute of Procurement & Supply has general guidance on contract risk allocation that applies well beyond software procurement, if you want a broader reference on how risk transfer works commercially.
✦ Where this fits
More on this from us: how our pricing works.