Fixed Price vs Time and Materials: Choosing Without Getting Burned

Pick a fixed price when the scope is genuinely closed, and time and materials when it is not. That settles the fixed price vs time and materials question for maybe half of the briefs that reach us. The other half is what this article is about, because most projects sit somewhere in between, and the model you sign decides how the relationship behaves on the day something goes wrong.

I have spent ten years on all three sides of that signature — writing the code, running the delivery, and quoting the work for the person paying. The part nobody writes about is the third one. A contract model is not a pricing mechanism. It is a set of incentives that only reveals itself under stress.

The short version

Neither is dishonest. Both are misused constantly.

What a fixed price actually prices in

A fixed price is not a discount for certainty. It is a bet the supplier makes, and like any bet it is priced.

The risk premium

When I quote a fixed price, I am quoting my best estimate plus a buffer for everything I cannot see from the brief. The third-party API that turns out to be rate-limited. The legacy data that is dirtier than described. The stakeholder who has not been in a meeting yet but will have opinions.

That buffer is real work that may never happen, and you pay for it either way. On a well-understood project it is small. On a vague one it is large, because a supplier who does not pad a vague fixed price either does not understand the brief or is planning to recover the difference somewhere else.

This is the trade that gets misread. Clients often assume a fixed price is cheaper because the number is smaller than the open-ended alternative feels. It is usually the more expensive of the two when the project runs smoothly, and the cheaper one when it does not. You are buying insurance, and insurance has a premium.

The change-request tax

Under a fixed price, the scope document is the contract. Anything not in it is a change, and a change is a commercial event: scoped, priced, approved, scheduled.

That process has a cost nobody quotes. Someone writes the change request, someone estimates it, someone approves it, and the work waits while that happens. For a small change the administration can cost more than the change. So small improvements do not get made. The product ships exactly as specified, including the parts that everybody realised were wrong in week three.

The thing to understand is that this is the contract working correctly. You asked for a fixed scope at a fixed price; change control is how that is protected. It is only a problem if you expected to be able to change your mind.

The incentive to cut scope quietly

This is the one that damages relationships, and it is structural rather than dishonest.

Once a fixed price project is running behind, the supplier's margin is the only variable left. The date is committed, the price is committed, the scope is written. What gives is the part of the work nobody specified in detail: error states, empty states, the admin screens, test coverage, accessibility, the second-tier browser, the documentation.

Nobody announces this. The build passes acceptance because acceptance was written against the features, not against the finish. Then you live with it. The pattern is visible from the outside if you know where to look — a demo that only ever shows the happy path, a QA phase that shrinks, a handover with no written documentation. We have seen the same shape when clients bring us work that was built fast and cheap somewhere else, which is the subject of rebuilding an AI-built app for production.

The defence is to specify quality, not just features. Put browser support, accessibility level, test expectations and documentation in the scope as deliverables with their own acceptance. If they are in the contract, they cannot be the flex.

What time and materials demands of you

Time and materials is often sold as the flexible, grown-up option. It is, if you can meet its conditions. If you cannot, it is worse than a fixed price, and I will say so before quoting it.

Attention

T&M assumes the client is present. Someone on your side has to review work in progress, answer questions within a day or two, and notice when the direction is wrong. Not a monthly steering committee — a person with context who reads the update and replies.

Where that person does not exist, the team builds on assumptions. Assumptions get discovered late. You pay for the rework, because under T&M rework is billable. A fixed price at least forces the supplier to own that cost.

Decisions

The second requirement is decision authority. T&M burns budget while a question sits unanswered, and the questions are rarely technical — they are business questions about edge cases nobody had considered.

If every decision has to go through a committee that meets fortnightly, T&M will cost you more than the same work fixed. You are paying by the hour for a process that runs by the month.

A budget cap you actually enforce

An uncapped T&M contract with a client who is not watching is the single worst arrangement in this business, and I include the bad fixed price contracts in that comparison. There is no natural stopping point. Every week produces progress and an invoice, and the question "is this still worth it" never gets forced.

Cap it. Put a ceiling in the contract, review burn against it monthly, and agree in writing what happens when it is reached.

The middle ground most projects should use

In practice, most of the work we take on is not purely one or the other. Two hybrids cover almost everything.

Capped time and materials. You pay for hours worked, the supplier cannot invoice past an agreed ceiling without written approval, and you get a burn report every month. You keep flexibility, you keep a budget you can defend internally, and the supplier keeps the incentive to be efficient because the cap is real.

The clause that matters is what happens at the cap. "Work stops" is honest. "We finish the agreed scope at our cost" is a fixed price wearing a T&M hat, and it will be priced as one. Decide which you are buying.

Phased fixed price. Break the work into phases. Scope each phase in detail immediately before it starts, fix the price of that phase only, and leave later phases as an indicative range rather than a commitment.

This is what we use for most custom software development of any size. It gives you a hard number for the next three months and an honest range for the rest, and it means you are never fixing the price of work whose requirements will be rewritten before it starts. It depends completely on a real discovery phase at the front, because a phase cannot be fixed-priced until somebody has done the work of closing its scope.

The multi-tenant billing platform in our HisaabKar case study is the shape of project that suits this — payment allocation rules, inventory costing and an audit trail are each a phase with its own logic to settle, and pretending you could price all of it accurately up front would be a guess dressed as a quote.

Fixed price vs time and materials when something goes wrong

Here is the part that decides projects, and almost nobody writes it down: the two models fail in opposite directions, and the failure mode is more important than the price.

Under a fixed price, a problem becomes a dispute. The moment the work turns out to be larger than specified, both parties' interests diverge. You want it delivered as agreed. The supplier wants it recognised as a change. Every conversation now has a commercial subtext, including the technical ones. Engineers start asking whether something is "in scope" before asking whether it is right.

The relationship goes formal. Emails get carbon-copied. Someone rereads the scope document looking for a sentence that helps. Whatever collaborative goodwill existed is now spent on establishing whose fault it is, and neither of you is working on the software.

Under time and materials, a problem becomes a bill. There is no dispute about whose responsibility it is, which removes the adversarial dynamic entirely. But the cost lands on you, visibly, in the next invoice. If the problem was the supplier's incompetence, T&M means you pay them to fix their own mistake, and the contract gives you no lever except stopping.

That asymmetry is the real choice:

• Fixed price protects your money and puts your relationship at risk.
• Time and materials protects your relationship and puts your money at risk.

Choose based on which of those you can better afford to lose, and on how much you trust the supplier. A fixed price is the right instrument for a supplier you do not know well, because it limits the damage of being wrong about them. T&M is the right instrument for a team you have worked with, because it removes friction you no longer need.

The agile principle of responding to change over following a plan is often quoted at this decision, usually by someone selling T&M. It is a fair point, but it is a statement about how to build software, not about who carries the risk of building it. You can run an iterative process under a fixed price. You just cannot change your mind for free.

Which model fits which project

That last row is not negotiable for us. Quoting a fixed price to fix code you have not read is either reckless or padded, and both are bad for the client.

Clauses that matter more than the model

Whichever model you sign, these decide how it actually plays out. Every one of them is worth more attention than the day rate:

• A written definition of done that covers quality, not only features — browsers, devices, accessibility, test coverage, documentation.
• What happens at the cap or the scope boundary. Work stops, work continues at cost, or a renegotiation is triggered. Pick one and write it down.
• Who owns the code and the accounts, from day one rather than on final payment. This and the rest of the pre-signature checklist are in our guide to questions to ask a web developer before hiring.
• A change process with a size threshold, so trivial changes do not need a formal request. Without this, a fixed price project accumulates unfixed small problems.
• Named people, not named roles, with a clause about substitution.
• An exit clause that says what you receive if you stop: repository access, deployment instructions, credentials, and work in progress.

If a supplier resists all of these, the contract model is not your problem.

How to actually decide

Answer three questions, in this order.

Can you write the scope down today, in enough detail that a stranger could build it? If yes, a fixed price is available to you and probably sensible. If no, stop — you are choosing between pricing a guess and paying for the work to remove the guesswork. The second is cheaper.

Do you have someone who can make decisions weekly? If no, avoid T&M regardless of how well it suits the work, or fix that problem first. It is the single biggest predictor of whether a T&M project goes well.

How much do you trust this supplier? Low trust argues for a fixed price on a small first phase — a real project, paid for, that tells you how they work before you commit to anything larger. We would rather be hired that way, and so would any agency confident in its delivery.

The decision rule I give clients is simple enough to remember: fix the price of what you understand, cap the cost of what you do not, and never fix the price of something nobody has looked at yet. If you are still deciding whether the software should be built at all, that question comes first, and we covered it in custom software vs off the shelf.