How to price a fixed-scope AI engagement instead of selling days
6 minute read. Updated 2026-08-08.
Don't fix a price before you've seen the data. Sell a short, fixed-fee diagnostic first, priced off your advertised day rate, that produces a written scope and a costed proposal for the build. Price the build itself against that scope, anchored to the median day rate for your role and moved toward the 90th percentile only where you can name a specific risk driving it.
The day rate is a ceiling
A day rate looks like an advantage until you notice what it actually does: it puts a public number next to your name. Advertised UK contract rates over the six months to August 2026 put the median Machine Learning Engineer day rate at £575, Data Scientist at £600, Data Engineer at £500. A hirer with that page open will not pay you double it without a reason they can defend upward inside their own organisation.
Selling days also puts you on the wrong side of every conversation about progress. If the work runs long, the question becomes whether you were slow. If it runs short, the question becomes why you charged for the days you didn't need. Neither question has anything to do with whether the thing you built was worth having.
The pitch that gets thrown back at contractors is fixed price: quote one number for the whole engagement, take the risk, keep the upside if you're efficient. That is not automatically the better trade, and treating it as one is how experienced people end up underpricing badly.
Why fixed price on day one is a trap
Before you've looked at the data, you don't know what's in it. A churn model brief that reads like a straightforward job can hide a customer ID field that changes meaning several times across the warehouse, or a label column backfilled by 3 different analysts using 3 different definitions. You cannot price around a problem you haven't yet found.
Quoting a fixed price against that unknown forces a choice. Pad the number heavily enough to cover a risk you can't specify, and you look expensive against the advertised rate the buyer is holding. Price it tight, and you eat the overrun yourself when the data turns out worse than the brief implied.
A pure day rate avoids this by pushing discovery risk onto the client's budget instead of your margin, and that's a real advantage of time and materials. The fix isn't to abandon fixed price. It's to stop fixing a price before you've scoped the work.
Sell the diagnostic, not the build
Split the engagement into 2 sales. The first is a short, bounded piece of work with a single deliverable: a written scope, a list of what you actually found in the data or the system, and a fixed price for the build that follows. Charge for this diagnostic as a fee in its own right, not as a free proposal.
This does several things at once. It gets you paid for the scoping work most contractors give away. It gives the client something concrete to evaluate before committing to a build price, which lowers the bar to booking you at all. And it converts an unscoped, unpriceable problem into a scoped, priceable one, which is the only kind of problem worth quoting a fixed price against.
Pricing the diagnostic
Anchor the diagnostic fee off the advertised day rate for your role, then quote it as a flat fee rather than as days sold. A diagnostic priced at 4 days, at a Data Engineer median day rate of £500, is 4 times £500, or £2,000. Priced at 5 days it's £2,500.
Quoting it flat, even though you calculated it from a day count, matters because it stops the conversation becoming about your speed. The client is buying a scope document and a costed proposal, not renting your time by the hour.
Pricing the build once you know what's in it
Once the diagnostic is done, you have something you didn't have before: a scope you wrote yourself, based on what you found. Price the build against that, using the advertised day rate for your role as the anchor and moving from the median toward the 90th percentile depending on how much residual uncertainty the diagnostic didn't remove.
Clean data and a well-understood pipeline justify pricing close to the median, £575 a day equivalent for a Machine Learning Engineer. Integration risk you can name but not fully quantify, an upstream system you haven't been given access to yet, justifies pricing toward the 90th percentile, £738 for the same role, or £788 for a Data Scientist, and you should say why in the proposal.
State the day-rate equivalent, the number of days it implies, and the margin added for the risk you're now carrying instead of the client. A buyer who can see the arithmetic argues with the assumptions, not with you.
Protect the price with the contract, not the invoice
A fixed price only holds if the scope holds. Write the diagnostic output as the definition of what the build price covers, and state that anything outside it is a change request, priced separately, before work starts on it. Without that line, scope creep erodes a fixed price faster than any day rate ever gets challenged.
Put a shelf life on the build quote, 2 to 4 weeks is reasonable, so a client can't sit on your scoping work for months and expect the same number once the market and your diary have moved on. And if the engagement sits inside IR35, the client makes that determination, not you, which changes how the fee should be structured. Settle that before you fix a price, not after.
What to do about it
- Do not quote a fixed price before you've seen the data or the system.
- Sell the scoping phase as a paid, standalone deliverable, not a free proposal.
- Anchor build pricing to the advertised day rate for your role, and show the arithmetic.
- Move toward the higher percentile only where you can name the specific risk driving it.
- Put a shelf life and a change-control clause on every fixed-price quote.
- Settle the IR35 determination before you fix a number, not after signing.
Questions people also ask
Isn't a paid diagnostic a hard sell to a client who just wants a quote?
It's an easier sell than it sounds. Most clients have already had one AI engagement quoted badly and are wary of a number produced without anyone looking at their data first. A short, fixed-fee diagnostic gives them a cheap way to test working with you and a real, defensible scope at the end of it. Frame it as de-risking their decision, not as an extra hurdle before the real work starts.
What if the client refuses to pay for a diagnostic and wants a free scoping call instead?
A short call to establish fit is reasonable to give away. A written scope with findings and a priced proposal is work, and giving it away sets the expectation that scoping is free on every future engagement, with every other contractor they compare you to. Draw the line at the point where you're producing a deliverable, not just having a conversation.
How many days should a diagnostic run?
Long enough to see the real data or system, short enough that the client's exposure if they decide not to proceed stays small, typically a handful of days rather than weeks. The right length depends on the problem, but the test is whether you can honestly write a scoped, priced proposal at the end of it.
Should I ever go back to pure day rate?
Yes, for open-ended advisory or ongoing operational work where there's no single deliverable to fix a price against, such as sitting inside a data team as extra capacity. Fixed-price logic applies to bounded pieces of work with a defined end state. Don't force it onto engagements that are genuinely ongoing.
Where the figures come from
Every rate and salary quoted in this article is a median or percentile of figures advertised in UK job postings over the six months to 8 August 2026. They are not rates paid, and the gap widens at the top of a range.
- IT Jobs Watch, UK contract rates, 6 months to 8 August 2026, read 2026-08-08.
- IT Jobs Watch, UK permanent salaries, 6 months to 8 August 2026, read 2026-08-08.