Part 3: Why Fixed-Price Delivery Gets Safer with AI

Fixed-price software delivery has always carried a particular tension, both for the teams delivering it and the organisations commissioning it. For delivery partners, the fear is the small number of tasks that go badly wrong and swallow the margin. For clients and internal tech teams, it's the blowout that delays a go-live, blows a budget approval, or erodes confidence in a programme they've already committed to.

In our first study from November 2025, we found that AI's measurable benefit was not speed but reduced variance. This is Part 3, the final part of our three-part AI productivity series for our February findings. If you haven't already, check out the previous blogs in this series: Part 1 covers how we measure AI use honestly, and Part 2 covers why AI adoption is a capability you build, not a tool you switch on. In this part, we look at why fixed-price delivery gets safer with AI.

The risk in fixed price was never the average task

On a fixed-price engagement, the average task landing close to estimate is not where the money is won or lost. It's the outliers, meaning the task that runs 50%, 100%, 200% over, that distort budgets, compress timelines, and erode client confidence. A handful of those can turn a healthy engagement into a loss.

So the right question for AI was never "does it make the average task faster?" It was "does it reduce how often a task goes badly wrong?" With a larger dataset this round, the answer is a clearer yes than before.

The mean barely moves. The tail collapses.

When we compare AI-assisted fixed-price tasks against non-AI work, the average overrun is essentially unchanged. Tasks are not, on average, finishing dramatically faster.

But the extremes tell a completely different story. Here, large overruns happen far less often on AI-assisted work, and the very worst outcomes, like tasks running to multiples of their estimate, are sharply rarer.

In other words, AI isn't shifting the middle of the distribution. It's cutting off the dangerous tail. For fixed-price delivery, that's the half of the distribution that actually matters commercially.

This is consistent with what we saw in our first study and with the broader research on AI-assisted development. We saw that AI improves predictability before it improves raw speed. Developers aren't finishing faster so much as finishing more reliably.

The more AI is used, the safer the task

The strongest version of this finding is the dose-response pattern. Tasks where AI was a primary tool throughout instead of an occasional assist, came in on or under budget the overwhelming majority of the time, with tail risk approaching zero.

There's a nuance worth being honest about that developers tend to lean hardest on AI for the tasks that are already running difficult. So some of the heavy-use population is hard work that AI is pulling back into line, rather than easy work being made easier. That makes the tail suppression on those tasks more impressive, not less. That means it's holding up precisely where the risk was highest.

The operating model this points to is not "some AI somewhere on the project." It's AI as a primary tool throughout the work. That's where the risk profile genuinely changes.

A hypothesis: the time goes into quality, not speed

If the average task isn't getting faster but is getting more reliable, where does the AI assistance actually go? We have a hypothesis, supported by the pattern in our data and by external research, though not yet something we can prove with our current measures.

A core mark of a good developer is choosing the right solution for the time available, and not rushing to something that merely works. AI may be letting developers spend the time they'd have spent fighting a problem on doing the job better instead. That means more thorough testing, fewer regressions, cleaner implementations, and more polished output. Those gains don't show up as a shorter task. They show up later, as fewer defects and higher client satisfaction.

We're upfront that this is a hypothesis. Proving it needs different data, like defect rates, rework, satisfaction scores, and that's on our list. But a flat average sitting on top of dramatically reduced variance is exactly what you'd expect to see if time saved is being reinvested in quality rather than banked as speed.

What this changes for delivery leaders

The reason this matters beyond our own walls is that it changes the risk calculus of fixed-price work. The thing that makes fixed price commercially hazardous is tail risk. It’s that unpredictable blowout. When that risk is reliably reduced, fixed price becomes a materially safer structure to commit to, and predictability itself becomes something you can offer clients with confidence.

There's a client side to this that's easy to miss when the focus lands on margin. Tighter delivery isn't only about avoiding blowouts, but also more work lands on or ahead of schedule, so clients get working software in their hands sooner and start realising its value earlier. On fixed price the client already has cost certainty; more predictable delivery adds time certainty on top, and often shortens the path between a signed scope and a result they can actually use. The same predictability that protects our margin shortens the client's time to value.

We're careful not to overclaim. The data doesn't say fixed price is risk-free, and it shouldn't be read that way. What it says is that the risk profile has shifted enough to be worth revisiting how delivery is planned, committed, and priced. Plans hold together more often. Forecasts are steadier. Commercial conversations start from a more confident footing. Those are durable advantages, and they accumulate quietly long before they ever show up as a headline speed metric.

Fixed-Price Delivery: Key Findings

Finding 1: The commercial risk in fixed price is the tail, not the average. A few tasks running far over estimate do the damage. The average task landing on time was never where margin was lost.

Finding 2: AI suppresses the tail while leaving the average flat. AI-assisted fixed-price tasks overran far less often and by smaller margins; the very worst outcomes became markedly rarer. The mean barely moved.

Finding 3: The protection is dose-dependent. Where AI was a primary tool throughout, tasks came in on or under budget the large majority of the time, with tail risk approaching zero, even on hard work.

Finding 4: The flat average may hide a quality gain. A plausible, research-supported hypothesis is that time saved is reinvested in quality, like better testing, fewer regressions, rather than banked as speed. We're working to measure this directly.

Finding 5: The fixed-price risk profile has genuinely changed. Not risk-free, but reliably less exposed to blowouts. It’s enough to warrant rethinking how fixed-price work is planned, committed, and priced.

Fixed-Price Delivery FAQs

Q: Does AI make fixed-price projects more profitable?

It does, but indirectly. To overturn that, you need to start by tracking overrun frequency rather than average task speed, which is where the commercial gain shows up first. AI's biggest impact is on the tasks that would have blown the budget, not the ones that were already running fine. Measure how often your worst-case tasks exceed estimate, introduce AI as a primary tool on those high-risk tasks, and watch that number drop.

Q: What's in it for the client, not just the delivery partner?

Quite a lot actually. Just remember to use the improved predictability as a commercial conversation, instead of an internal metric. When your delivery variance tightens, you can offer clients something more valuable than a fixed price: a fixed price and a reliable timeline. That means working software in their hands sooner and value realised earlier. Cost certainty is table stakes while time certainty is the differentiator.

Q: Why focus on fixed-price rather than time-and-materials?

Because fixed price is the clean before-and-after signal. If you want to measure what AI is actually doing to your delivery, you need to run the analysis on your fixed-price work first. Every task is measured against a commitment made before work started. Use that data to build your baseline, then apply the lessons to how you scope, estimate, and staff time-and-materials engagements too.

Q: What does "tail suppression" mean?

It means the extreme overruns become rare, so you need to focus your AI adoption effort on your hardest, highest-risk tasks and not just your average ones. The way to capture that benefit is to make AI a primary tool on the work that historically runs the furthest over estimate. That's where the protection is strongest, and that's where your margin is most exposed without it.

Q: Is AI making developers faster or just more reliable?

On our data, more reliable. We made sure to measure reliability first, and use it to build the case for deeper adoption. Right now, the clearest, most defensible gain is in consistency. That means fewer overruns, tighter outcomes, more work landing on or under budget. Track that then report it. Speed gains are emerging over a longer period, and having a reliability baseline already in place means you'll see them clearly when they arrive.

Q: Does this mean fixed-price work is now safe with AI?

Safer, not safe, so treat the improved risk profile as an opportunity to sharpen your scoping and delivery practice, instead of relaxing it. AI has shifted the odds in your favour, which means you can now commit to fixed-price engagements with more confidence and price them more competitively. Use that advantage deliberately to tighten your estimation process, brief your teams on where AI delivers the most protection, and have the conversation with clients from a position of demonstrated reliability rather than assumed risk.

Capturing the Value of More Predictable Delivery

Reduced delivery risk is one of the most commercially meaningful effects of AI. It’s also one of the easiest to leave on the table if you can't measure it.

We've quantified this shift inside our own delivery. We know where the protection is strongest and where it doesn't show up yet. We also know how to structure work to capture it deliberately rather than accidentally.