Fixed Price vs Time and Materials: Which Contract Protects You

You have two proposals on the table for the same project. One firm offers a fixed price. The other insists on time and materials and explains, at length, why fixed price is bad for you. Both will tell you their model is the one that protects the client. Both are partly right. Which contract actually protects you depends much less on the vendor's preference than on one question: how well do you know what you are building? Here is how each model distributes risk, where each one is honestly the right choice, and what we put in writing ourselves.

What each model actually commits to

A fixed-price contract commits the vendor to a defined deliverable for a defined amount. If the work takes longer than the vendor estimated, that is the vendor's problem. If the deliverable was defined loosely, that is everyone's problem, because every ambiguity turns into an argument about whether something was included. The model works only when the scope is written down well enough that both sides read it the same way.

Time and materials, usually shortened to T&M, means you pay for the hours worked at an agreed rate. You keep full flexibility: change the priorities on Monday, and the team works on the new priorities on Tuesday. The risk of overrun sits with you, and the vendor's only incentive to finish quickly is its reputation. A good T&M vendor manages that with estimates, weekly reporting and a cap. A poor one just sends invoices.

There are hybrids: a capped T&M contract, milestone-based billing, or a fixed price for phase one followed by T&M for what comes after. The hybrids exist because most real projects have a part that is known and a part that is not, and each part deserves the contract that fits it.

Where time and materials is the right choice

T&M is right when the scope is genuinely unclear and will stay unclear for a while. A product company building a roadmap over twelve months does not have a scope; it has a direction. Forcing that into a fixed price means renegotiating every two weeks, and the renegotiation costs more than the flexibility it removes. The same applies when you have strong in-house product leadership that wants to direct the team daily. In that case you are buying capacity, not an outcome, and capacity is priced by the hour.

T&M also fits research work, legacy systems nobody fully understands, and integrations with third-party systems whose documentation does not match reality. In all three, an honest vendor cannot estimate with confidence, and a fixed price would carry a risk premium you would pay whether or not the risk materialized. The dedicated team model is the natural home for this kind of work.

Where fixed price is the right choice

Fixed price is right for a defined first project, especially with a vendor you have not worked with before. An internal tool that replaces one spreadsheet and one email thread. A migration from a known system to a known system. A customer portal with a written list of user roles, screens and business rules. In these cases the scope can be written on a few pages and will hold for the two to four months the work takes, so there is no reason for you to carry the estimating risk.

It is also the right model when the budget has to be approved once, by a board, a CFO or a grant program, and cannot be reopened every month. And it is the fairest way to test a new partner: a fixed price forces the vendor to think before quoting, which is exactly the behavior you want to observe. The precondition is that the scope exists, which is why a fixed price should follow a short scoping sprint, not a sales call.

How a fixed price is made safe for both sides

The scoping sprint produces the document the fixed price rests on: user roles, screens, business rules written as rules rather than adjectives, integrations with their data flows, acceptance criteria for each milestone, and an explicit out-of-scope list. That last item is the one most proposals skip and the one that prevents most disputes. If a feature is not in the document and not on the out-of-scope list, nobody knows whether it was included, and that is where the arguments come from.

Change requests are the second safety mechanism. A change is anything that is not in the scope document. It is priced separately, in writing, before the work starts, and you decide whether to approve it. Small changes are bundled so that nobody spends more time on paperwork than on the change itself. The important part is that a change never becomes a surprise on an invoice; it becomes a decision you made with the number in front of you.

The third mechanism is definitions. A bug is not a change; fixing something that does not work as specified is part of the price. A new field on a form is borderline, so decide up front how borderline items are handled, for example by allowing a small pool of minor adjustments inside the fixed price. Payment tied to accepted milestones closes the loop: you pay for what has been demonstrated against the written criteria, not for calendar time.

Our policy, stated plainly

For a first project we work on a fixed scope at a fixed price. If we underestimated the work, the overrun is ours, not yours. If you change the scope, that is a change request with a price you approve before anything is built. We sign your NDA and your master services agreement rather than insisting on ours, and the code and the intellectual property are yours from the first day, in writing.

We do not publish hourly rates, and we do not argue that a fixed price is right for everything; the previous sections explain when it is not. What we do argue is that a company buying its first custom system from a new vendor should not be the one absorbing the estimating risk. How the number itself is built is covered in our guide to what custom software costs, and the engagement structure is described on our custom software development page.

Warning signs in both contract types

In a fixed-price proposal, be wary of a price delivered without questions about your business, a scope without an out-of-scope list, milestones without acceptance criteria, and a number far below every other bid. The low bid is rarely generosity. It is usually a plan to recover the difference through change requests once you are committed. A vendor who will not define what counts as a change is telling you the same thing in a different way.

In a T&M proposal, be wary of the absence of any estimate at all, of reporting that shows hours without the tickets those hours went to, of a team described as senior while the timesheets say otherwise, and of resistance to defining a clear end for phase one. A T&M vendor who cannot tell you, every week, how spent hours compare to the original estimate is not managing your budget. You are.

How to decide for your project

If you can write the scope on a few pages and it will hold for the next three months, ask for a fixed price and check that the proposal contains everything listed above. If you cannot, do not sign a fixed price; run a scoping sprint first, then fix the price for phase one, then decide about the rest with real information. If what you need is a team that follows your product roadmap for a year, T&M with a cap and weekly reporting is the honest answer, and you should say so to the vendors bidding.

If you want a second opinion on a proposal you already have, send it to us. We will tell you which model fits your project, including when the answer is not the one we would prefer.