Fixed price vs time and material: which contract fits

Choose fixed price when the scope is small and settled enough that a stranger could build it from the document and hand back what you meant. Choose time and material when the scope will move, and protect yourself with a cap, weekly visibility and a short notice period rather than with a fixed number. That is most of the fixed price vs time and material decision. The rest is about who carries the cost of a wrong estimate, and how each side behaves while carrying it.

Who carries the risk in each model

On a fixed-price contract the vendor agrees to deliver a defined scope for a set sum. If the work takes longer than they thought, they absorb it. On time and material (T&M) you pay for the hours or days actually worked, at an agreed rate. If the work takes longer, you pay for it.

The UK government’s buying guidance for digital services puts the trade-off in one line each. Fixed price can be more expensive because the supplier owns most of the risk, and it works best when requirements are well defined enough to quote without adding extra costs. With time and materials, the same guidance says, you own more of the risk.

Neither model removes the risk. It moves it. And early in a software project the risk is large. Steve McConnell’s Cone of Uncertainty describes how far skilled estimators have been off at each stage of a project. At the initial concept stage an estimate can be four times too high or four times too low, a 16x range from the lowest credible figure to the highest. McConnell’s advice is to avoid firm commitments until that range has narrowed, because a commitment made at concept or product definition carries a 2x to 4x error.

So a fixed price agreed on a vague brief is a number with a very wide error bar. Someone pays for that error bar. The contract decides who, and how visibly.

When fixed price works

Fixed price works when the thing being bought is small, understood and unlikely to change before it ships. Typical examples:

• An integration against an API that is already documented and stable.
• A defined feature on an existing product, such as a payment flow or an export.
• A migration with a known start state and a known end state.
• A first slice of a larger product, deliberately kept to a few weeks.

What these share is that the people who will sign off the work can agree, in writing and in advance, on what done looks like. The vendor has usually built something similar, so their estimate sits near the narrow end of McConnell’s cone rather than the wide end.

In the Standish Group’s original CHAOS survey, IT executives named a clear statement of requirements as one of the three biggest reasons projects succeed. Fixed price makes that a precondition rather than a hope. If you cannot write the requirements down clearly, you are not ready for a fixed price, and a vendor who quotes one anyway is guessing.

When the conditions hold, you get a known cost and little administration, and the vendor is rewarded for working efficiently. That incentive turns against you only when done is open to interpretation.

Where fixed price breaks down

Scope moves. On a new product it nearly always does, because the first users teach you things no specification anticipated.

The Standish survey is old, published in 1995, but its list of causes has not aged. The three most common reasons given for challenged projects were lack of user input (12.8% of responses), incomplete requirements (12.3%) and changing requirements (11.8%). Only 16.2% of projects in that survey came in on time and on budget, and the challenged and cancelled ones averaged 189% of their original cost estimate.

A more recent study shows why vendors are wary of the tail. Bent Flyvbjerg and Alexander Budzier looked at 1,471 IT projects and found an average cost overrun of 27%. One in six projects, though, overran its cost by 200% on average and its schedule by almost 70%. A fixed price that absorbs an average overrun may not survive a project in that tail, and an experienced vendor knows this when quoting.

Three things follow from that.

Padded quotes. A vendor taking on the risk prices it in. You pay for the contingency whether or not the risk turns up. This is why the UK guidance says fixed price can cost more.

Change-request fights. Every ambiguity in the specification becomes a negotiation. The vendor’s incentive is to read the scope narrowly and yours is to read it broadly. Weeks go into arguing about what was included, and that time builds nothing.

The invisible cuts. When the money runs out before the work does, something has to give. It is rarely the feature you can see in a demo. It is more often the tests, the error handling and the documentation, which you only discover later.

Martin Fowler made the underlying point in 2003. You can fix the price, but on work where learning changes the plan, fixing the scope as well does not hold. His alternative is to fix the budget and the date, then agree together which features give the most value within them.

A fixed price does not remove the risk of a wrong estimate. It moves that risk to the vendor, who charges you for carrying it. Time and material leaves the risk with you, so it only works if you can see where every hour went, every week.

What protects you on time and material

The fear with T&M is an open cheque. The answer is not trust. It is a handful of terms that make overspending visible early and leaving cheap.

Weekly visibility of shipped work. A demo, a staging build or a release you can use, every week. A status report is not the same thing. If a week passes and nothing you can see has changed, you should know why by Monday.

A cap. Capped T&M is the same as T&M with a limit on what you pay. In the UK government’s version, if the limit is reached before the work is finished, the supplier completes it at their own cost. A softer form is a monthly ceiling that needs your written approval to exceed. Be aware that a hard cap brings back some fixed-price behaviour. The vendor will now think about contingency again, and may ask for a tighter scope.

A time log you can read. The invoice should be backed by a log with a date, the hours, what was done and a link to the ticket or the commit. A single line reading “development, 160 hours” is not a log. If you cannot check a line against the work, you cannot challenge it.

A short notice period. If you can leave with two weeks’ notice, the vendor has to earn the next two weeks, every two weeks. A long lock-in removes the main discipline T&M has.

Your code in your account. The repository, the cloud accounts and the app store listings should belong to you from the first day. That makes leaving a decision about the vendor, not a hostage negotiation.

For reference, our own hourly work is $35 an hour, invoiced monthly against a log you can read line by line, with two weeks’ notice either way. The details are on the pricing page.

Hybrids that split the difference

Most well-run engagements are not purely one model. They use fixed price where the scope is narrow and T&M where it is not.

Fixed-price discovery, then T&M. A short, fixed piece of research and design before any commitment to build. The UK Government Service Manual says 4 to 8 weeks is typical for discovery, and that you should not start building during it. The benefit is that the cone narrows before you commit real money. The cost is that you pay for documents rather than software.

A fixed-price first slice, then T&M. Instead of paying for research, pay a fixed sum for a small piece of working software. It narrows the cone in the way McConnell describes, by forcing decisions, including decisions about what you will not build. It also lets you judge the vendor on something that runs rather than on a proposal. This is how most of our engagements start: a fixed-price two-week piece at $2,800, then hourly at $35 or embedded monthly at $5,400 if both sides want to continue. The process page sets out the steps.

Milestone-based fixed price. The work is split into milestones, each priced and accepted separately. It works if you can define acceptance for each milestone and are willing to re-price later milestones as you learn. It fails if the milestones are just a fixed-price project cut into invoices.

Target cost with a maximum. The UK government’s sourcing playbook describes a model where the vendor bids a target cost plus a margin, and a guaranteed maximum price sits a set percentage above it. Savings below the target are shared, overruns above it are split equally, and the client never pays more than the maximum. The playbook suggests it for work where outputs are known but delivery methods are not. It takes more effort to agree than a plain cap, which is worth it mainly on larger contracts.

Dedicated team or retainer. You pay monthly for a set amount of a person’s time rather than for a deliverable. It is T&M with a fixed quantity, and it suits ongoing product work where priorities change week to week. The risk is paying for a seat you no longer need, so the notice period and a weekly look at output matter just as much here.

McConnell describes a middle ground many teams settle on. They define most requirements up front and then build in short iterations. By his figures this brings estimate variability down to about plus or minus 25%, which is tight enough to plan a budget around.

How to write a scope either model can survive

A good scope helps under either contract. On fixed price it limits the arguments. On T&M it shows what the hours are buying.

Write outcomes with acceptance checks, not feature names. “Password reset” is a feature name. “A user can reset their password by email, the link expires after an hour, and it works on iOS and Android” is something both sides can test.

Say what is out. McConnell’s white paper notes that the cone narrows as you make decisions, and that deciding what you will not do counts. An explicit out-of-scope list prevents more disputes than any other paragraph.

List assumptions and dependencies. Who supplies the designs, and by when. Which third-party APIs you already have access to. Who provides content, test accounts and app store credentials.

State the non-functional requirements. Which platforms and browsers. Roughly how many users. What counts as fast enough. Accessibility and languages.

Define done. Deployed where. Whether app store submission is included. What handover documentation you get.

Describe the change process. How a change is raised, estimated and approved, and who on your side can approve it. On fixed price this is the pressure valve. On T&M it is how you keep the backlog honest.

Name your decision-maker and a feedback turnaround. User involvement was the top success factor in the Standish survey. A vendor waiting a week for an answer is a cost under either model.

Choosing fixed price vs time and material

A few questions settle most cases.

• Could you write an acceptance check for every item in the scope today? If yes, fixed price is viable.
• Will what your first users do change what you build next? If yes, use T&M or a hybrid.
• Do you need a firm number for a budget approval? A fixed-price first slice followed by capped T&M gives you a number and an exit.
• Have you worked with this vendor before? If not, start with something small and fixed, so you learn about them for a bounded sum.

Watch how a vendor responds to the protections. One who refuses weekly demos, readable logs or a short notice period is telling you how the engagement will feel. If you want a rough cost range to take into either conversation, the estimator gives one from the type of build and the features you tick.