Fixed price vs time and materials: which contract is right for your software project?

You have a software project, a shortlist of developers, and two very different quotes. One says "$60,000, fixed." The other says "$150 an hour, estimated 400 to 500 hours." Which one is the better deal?

Here is the short answer. A fixed price contract sets one price for a defined scope, so the developer carries the risk of the work taking longer. Time and materials (T&M) bills for the hours actually worked, so you carry that risk but keep the freedom to change direction. Fixed price fits small, well-defined projects. T&M fits work where you will learn as you go. For most custom software, a hybrid works best: a fixed-price discovery phase, then T&M or capped sprints.

How does a fixed price contract work?

You and the developer agree on a written scope: features, screens, integrations, and what "done" means. The developer quotes one price for that scope, usually paid in milestones (for example, 30% at start, 40% at a mid-point demo, 30% at launch).

If the work takes longer than planned, that is the developer's problem. If you want something that is not in the scope, it becomes a change request with its own price.

What fixed price gives you:

• A known number for budgeting and board approval
• Less time spent tracking hours
• A clear finish line

What it costs you:

• A risk premium. The developer cannot know everything up front, so they pad the quote. You pay for that padding whether the risks happen or not.
• Rigidity. Every change goes through a formal process, which slows things down.
• Scope arguments. When the spec is vague, "is this included?" becomes the main conversation.

How does time and materials work?

You pay for the time the team actually spends, at agreed rates, plus any direct costs like paid APIs or licenses. You usually get an estimate rather than a promise, and the team works in short cycles (often two-week sprints) with a demo at the end of each.

What T&M gives you:

• Flexibility. You can reprioritize every sprint based on what you learn from users.
• No padding. You pay for real work, not for the developer's insurance against unknowns.
• Faster start. You do not need a perfect spec before anyone writes code.

What it costs you:

• Budget uncertainty. The final number can move.
• More of your attention. You need someone on your side who reviews progress and makes decisions every week or two.
• Weaker incentive to be efficient. The US government puts this bluntly in its own contracting rules: the federal acquisition regulation on T&M contracts says the model "provides no positive profit incentive to the contractor for cost control." That is why the same rules require a ceiling price and active oversight. The lesson carries over to private buyers: T&M works when you watch it.

Who carries the risk in each model?

This is the real question behind fixed price vs time and materials. Software always has unknowns: an API that behaves differently than documented, a feature users ignore, a requirement nobody thought to mention.

• Fixed price: the developer carries the risk of effort. You carry the risk of getting exactly what you specified, even if it turns out to be the wrong thing.
• T&M: you carry the risk of effort. The developer carries very little, but you keep the ability to build the right thing.

Notice that neither model removes risk. It just moves it. The federal rules make the same point from the other side: they say a firm fixed price fits work with clearly defined specifications, where a fair price can be set at the outset, and that T&M may be used only when the extent or duration of the work cannot be estimated with reasonable confidence. Their logic applies to a 10-person company just as well as to a federal agency.

What happens with change requests?

Change is normal in software. PMI's 2026 look at project success notes that teams willing to flex time, cost or scope in service of value get stronger results, and that about 45% of projects that ended up successful were seen as at risk at some point along the way. Your contract should expect change, not punish it.

On fixed price, each change is written up, priced and approved before work starts. Ask in advance:

• How are change requests priced (hourly rate, or fixed per change)?
• How fast will you get a quote for a change?
• Can you swap a feature for one of similar size at no cost?

That last one matters. A "swap" clause lets you trade a planned feature for a new one without paperwork, which takes a lot of friction out of fixed price.

On T&M, a change is just a new item in the backlog. It gets prioritized against everything else and built when there is room. The budget question becomes "what do we drop or delay to make room for this?"

When does each model fit?

Fixed price fits when

Fixed price is a good choice when:

• The scope is small and well understood (a marketing site, a single integration, a clear set of reports)
• You have a detailed spec or the output of a discovery phase
• The work is similar to something the developer has built many times
• Your budget truly cannot move, and you would rather cut scope than spend more

If you are still working out what to build, a fixed price quote is mostly a guess with a premium on top. A clear written brief helps a lot here, and our guide on writing a software brief or RFP walks through what to include.

Time and materials fits when

T&M is usually the better fit when:

• You are building something new, like an MVP, where user feedback will change the plan
• The project is long-running or ongoing (new features every month, maintenance)
• Requirements depend on things you cannot know yet, like how a third-party system behaves
• You have someone on your side with time to review demos and make calls

T&M also suits ongoing improvement after launch, which is where most software spend ends up over its life.

Whichever model you pick, the scope lives in the statement of work. Here is what a software SOW should contain.

What does a hybrid look like?

Most buyers do not have to pick one or the other. The common hybrids:

Fixed discovery, then T&M. A short, fixed-price discovery phase (often 2 to 4 weeks) produces a scope, wireframes, a technical plan and a cost range. You then build on T&M with that range as a guide. You get a clear, small first commitment and a far better estimate for the rest. This is how we prefer to start most projects, because it gives you something written to decide on before you spend serious money.

Capped sprints. Each sprint has a fixed price or a fixed number of hours. You decide at the end of each one whether to continue, change direction or stop. Your maximum exposure is one sprint at a time.

T&M with a not-to-exceed cap. The developer bills hours, but only up to an agreed ceiling for a phase. If they get close to the cap, they must tell you early and agree a plan with you before going over.

Fixed price per milestone. The project is split into phases, each with its own fixed price, quoted only when the previous phase is done. Later quotes are more accurate because they are based on what you learned.

To see what a realistic budget looks like before you choose a model, our custom web app cost guide breaks down market ranges by type of project.

Quick answers

Is fixed price cheaper than time and materials?

Not usually. Fixed price includes a risk premium for unknowns, so the same well-run project often costs less on T&M. Fixed price is more predictable, not cheaper.

Can a fixed price project still go over budget?

Your invoice should not, but your total spend can. Change requests, missed requirements and "phase 2" work are all billed on top. The more vague the spec, the more likely that is.

How do I stop a time and materials project from running away?

Set a cap per phase, ask for a short weekly report of hours and progress, and review a working demo every sprint. If the burn rate is ahead of the progress, raise it that week, not at the end.

Which contract model do agencies prefer?

Many prefer T&M for new products because it is fair when the scope is uncertain. Experienced agencies are happy with fixed price for well-defined work. Be cautious if a developer insists on one model for every kind of project.

Should discovery be fixed price?

Yes, in most cases. Discovery has a clear output (scope, wireframes, plan, estimate), so it is easy to price. It is also a low-risk way to see how a developer works before committing to the full build.

Next step

If you have quotes in hand and are not sure which contract model protects you best, we can look at them with you. Book a free call, share what you are planning, and we will send you a written recommendation within a few days.