Fixed price vs agile: which delivery model fits your project

What you are actually choosing

Both models can deliver the same software for a similar total. What differs is who carries the risk that the scope is wrong, and that single question explains every other difference between them.

Under a fixed price, the supplier carries it. They commit to a figure for a defined scope, so if the work proves harder than estimated, that is their problem — and they price for the possibility. Under agile, you carry it. You commit to a team and a cadence, direction is set as you go, and if the work proves harder you decide what to drop.

Neither is more honest or more modern. A supplier who tells you agile is always better is usually describing their preference for carrying less risk, and one who insists on fixed price for genuinely exploratory work is pricing in a contingency you will pay for whether or not it is needed.

How fixed-price delivery works

Everything is decided before contracting. Our fixed-fee approach plans and estimates the project up front, then contracts against that plan: a defined scope, defined timelines, defined deliverables, with clear milestones and approval checkpoints through build, testing and deployment.

The upfront planning stage is the whole mechanism. It defines scope, reduces risk and prevents scope creep — and without it a fixed price is a guess with a signature on it. That is why serious fixed-price work follows a paid planning engagement; on our projects Quickstart App Planning typically completes within 3 to 6 weeks and produces the scope and estimate that the contract is then written against.

The trade-off is that changing your mind has a price. Every alteration is a change request, priced and agreed, because the original figure was calculated against a specific scope. That is not a supplier being difficult; it is the arithmetic of having moved the risk to them.

How agile delivery works

Agile commits to a way of working rather than to a final scope. Work proceeds in short cycles, each producing something usable; priorities are reset at the start of each cycle based on what the last one taught you.

The commitment you make is to the cadence and the involvement, not the feature list. That involvement is not optional — agile without an available decision-maker degrades into a team guessing at priorities, which is the worst of both models. We typically recommend agile for projects that are ongoing or already released to customers, where evolving demands mean requirements genuinely should change in response to feedback or market conditions.

The value is that you can act on what you learn. The cost is that you cannot know the total at the outset, because deciding as you go is the point. The Agile Manifesto is refreshingly short if you want the original framing; GOV.UK's agile delivery guidance is a more practical modern treatment.

Side by side

Read this as a distribution of risk and control rather than a scorecard. The rows are not independent — moving scope risk to the supplier is what forces the change-request mechanism, and keeping it yourself is what buys the freedom to reprioritise.

• What you commit to. Fixed price: a scope and a figure. Agile: a cadence and a level of involvement.
• Who carries the scope risk. Fixed price: the supplier, priced accordingly. Agile: you.
• Changing your mind. Fixed price: a priced change request. Agile: expected, and free between cycles.
• When you know the total. Fixed price: before you start. Agile: not at the outset, by design.
• Your own time required. Fixed price: concentrated in planning and approvals. Agile: continuous, every cycle.
• What you need before contracting. Fixed price: settled scope, which means a paid planning phase. Agile: a clear first priority and an available decision-maker.
• Best for. Fixed price: known requirements, a fixed budget, and first builds that cannot absorb change. Agile: live products, evolving requirements, and work where feedback should redirect the build.

Two rows tend to decide it in practice: how much of your own time you can commit, and when you need to know the total. A business that cannot free up a decision-maker every fortnight will not get the benefit of agile however much it prefers the idea, and a budget that has already been approved by a board rarely tolerates a total that is unknown at the outset. Everything else is secondary to those two.

Fixed-price sprints: the practical middle

Most projects are neither fully known nor fully exploratory, which is why the useful answer is usually a hybrid: fix the price of a unit of work rather than of the whole project.

On our sprint-based delivery, each two-week sprint is a fixed price with a predictable number of Output Units — units of finished work rather than time spent — and scope is agreed per sprint. Most clients start with 2 to 4 sprints, commit one at a time, and most projects aim to launch a usable first version within 2 to 8 weeks.

The part that matters commercially is the exit. Escape Hatch Friday™ means telling us before 5pm on a Friday makes the current sprint your last, with no awkward conversations or legal wrangling. That is what removes the usual objection to open-ended engagements: you get agile's ability to change direction, with fixed-price certainty over the amount you are ever committed to at once.

A test for deciding

Four questions settle it in most cases.

1. Can you write down what you need, in enough detail that two suppliers would build the same thing? If yes, fixed price is available and probably sensible. If no, a fixed price will be priced defensively or renegotiated later.
2. Is the software already in front of users? If yes, lean agile — feedback should be changing what you build, and a fixed scope fights that.
3. How much of your own time can you genuinely commit? Agile needs a decision-maker every cycle. If nobody has that capacity, fixed price protects you from a team guessing.
4. What happens if it costs 30% more than planned? If that is survivable, agile's flexibility is worth more than certainty. If it is not — a grant, a board-approved budget, a fixed investment round — buy the certainty and accept the contingency inside it.

If the answers conflict, the hybrid is usually right: fix the price per sprint, keep the scope flexible, and cap your commitment.

Cost and timelines

Neither model is inherently cheaper. Fixed price includes a contingency you pay whether or not it is used; agile has no contingency and no ceiling. Over a portfolio of projects the totals tend to converge, which is why the decision should be made on risk and certainty rather than on a hoped-for saving.

On duration, fixed-price projects typically range from several weeks to several months, and we usually recommend delivering a brand-new project within three to six months. Shorter than that and it is a small project; longer and you are usually defining too many requirements up front, at which point an MVP approach that launches something smaller and sooner is the better answer.

For the floor on bespoke work generally, our quote page states that a project under £7.5k is unlikely and most of ours are more than that. Payment tracks delivery under either model: the worked example there is a £20,000 project over three months split into four payments, a deposit plus one at each month end.

How each model fails

Fixed price fails through the change-request spiral. The scope was agreed before anyone understood the problem, so every genuine discovery becomes a commercial negotiation. Relationships sour, and both sides start optimising for the contract instead of the software. The guard against it is a proper paid planning phase, and honesty about what is genuinely unknown.

Agile fails through drift. No fixed scope becomes no scope: sprints continue, the burn rate is comfortable, and nobody asks whether the original objective was met. The guard is an outcome and a budget review point agreed at the start, even though the feature list is not.

Both fail the same way when the customer is absent. Fixed price with no engaged approver produces software that meets the specification and not the need. Agile with no engaged decision-maker produces a team choosing priorities on your behalf. The single best predictor of a project going well is not the contract model — it is whether someone with authority is genuinely available.

Making the call

Decide the risk question first and the contract second. If your scope is genuinely settled and your budget genuinely fixed, buy a fixed price and accept the change-request mechanism that comes with it. If your product is live and learning, run agile and accept that you cannot know the total. If you are like most projects and sit between the two, fix the price of a sprint rather than of the project.

Whichever you choose, insist on the same three things: a written definition of what is in and out of scope, a named decision-maker on your side, and an agreed mechanism for change. Those matter more than the label on the contract.

If you would like a straight recommendation for a specific project, see how fixed-fee delivery works or book a free consultation and we will tell you which model we would use and why.