Fixed price vs time and materials: choosing a pricing model for software work

Choose fixed price when you can describe the finished result before work starts, time and materials when you can't yet but can steer the work closely, and a monthly team fee when the work is an ongoing roadmap. The real difference between the three is who pays when the scope or the estimate turns out to be wrong.

Pricing is a separate choice from the team model. If you are still deciding how to staff the work, start with our comparison of dedicated teams, staff augmentation and project outsourcing.

The three pricing models in plain terms

Fixed price

You agree the scope, acceptance criteria and price before work starts. Payment is tied to milestones and is usually released when each one is accepted. If the work takes longer than estimated, the vendor absorbs the cost. Anything outside the agreed scope goes through change control and is priced separately.

Time and materials

You pay for the time people actually spend, at agreed rates, usually invoiced monthly. You can change direction whenever you like, because you are buying effort rather than a defined result. If the work takes longer, you pay for the extra time.

Monthly team fee

You pay a set fee each month for a team that works on your priorities. Some vendors call it a retainer, others a managed team. As with time and materials, the scope can move sprint by sprint. Unlike it, the cost is known in advance and doesn't grow because a task took longer. Our managed engineering squads work this way: a flat monthly fee per squad, with no hourly bills.

Who carries the risk in each model

Every software contract shares out two risks. One is that the work takes longer than estimated. The other is that the scope turns out to be wrong or incomplete. Each model puts them in a different place.

• Fixed price: the vendor carries the estimate risk and you carry the scope risk, because anything you didn't specify becomes a change. Vendors add a buffer for unknowns to a fixed quote, so you pay for some risk whether or not it happens.
• Time and materials: you carry both risks. In return you get full flexibility and pay only for the work done. It works only if someone on your side compares progress with spend every week.
• Monthly team fee: the monthly cost is fixed and the scope is reset each sprint. The open question is how much the team gets done each month, so clear priorities and honest progress reports matter more than the contract wording.

When fixed price fits

Fixed price works when the result can be checked against something written down. Look for these signs:

• The features, users and integrations are known, and the list is unlikely to change during the build.
• Acceptance criteria are written, so both sides can agree when a milestone is done.
• Dependencies are understood: third-party APIs, data you need to supply and the people who must sign things off.
• You have a set budget, or a business case that needs a known number.

The main risk is false precision. A fixed price on a vague scope only moves the argument to the end of the project, when every gap becomes a dispute about what was included. A statement of work with the exclusions and assumptions written down protects both sides, and it gives change requests something clear to be measured against.

When time and materials fits

Time and materials suits work that nobody can honestly estimate up front. Examples are early product exploration, fixing an unfamiliar legacy system, or testing whether an idea is technically possible. It also suits short, open-ended help, such as a few weeks of performance tuning.

It asks more of you than the other models. Agree a monthly cap, so a slow month doesn't become a surprise invoice. Ask for a weekly view of time spent next to what was delivered. Without those two controls, you can end up paying for activity rather than progress.

When a monthly team fee fits

A monthly fee suits a product with a continuous roadmap: a live SaaS platform, an internal system that keeps gaining features, or any product after its first release. You set the priorities each sprint and the team lead plans the work. Because the bill doesn't depend on hours, the conversation moves from how long things took to what is worth doing next.

The risk here is drift. A team on a monthly fee can stay busy without moving the product forward. Expect a demo of working software every sprint and a short written update that ties the work to your goals. If either stops, ask why.

Combining the models across a project

The models work best in sequence, each one used where it matches how certain the work is. A pattern we recommend:

1. Discovery at a fixed price. A short, scoped phase to agree the users, architecture, scope, milestones and acceptance criteria. Its output is a delivery baseline you can price against. Make sure you own it whether or not you continue with the same vendor.
2. The first release at a fixed price, paid by milestone. With a baseline in place, the build can be quoted with a much smaller buffer.
3. A monthly team after launch. The product is live and the backlog keeps growing, so a stable team serves you better than a string of change requests.

This is close to how our project delivery is priced. Well-defined work can have a fixed price, paid against milestones. Complex work that needs discovery first can use a capped or phased structure until the delivery baseline is agreed. Many clients start with a project for a defined launch, then add a managed squad for ongoing development.

Questions to ask before you sign

1. What exactly is included, and what is excluded? A clear list of exclusions prevents more disputes than a long list of features.
2. What triggers each payment? A date, a delivery and an accepted milestone are very different things.
3. How was the estimate built? Ask to see the assumptions behind the number, not just the total.
4. How are changes priced and approved? Find out who on your side can approve one, and how quickly.
5. What happens if we supply data, access or decisions late? A fixed price usually assumes the client keeps to their side of the plan.
6. Under time and materials, is there a monthly cap? Ask too how you will see time spent next to what was delivered.
7. Who owns the code if we stop part-way? You should own everything delivered so far, and the agreement should say so.

Where to start

Write one page describing what done looks like. If you can fill it with features, users, integrations and acceptance criteria you are confident about, ask for a fixed price. If half of it is question marks, pay for a fixed-price discovery phase first. If the page describes a roadmap rather than a finish line, look at a monthly team.

To talk through which model suits your work, book a free 30-minute call. After the first call, we suggest the right model and give you a rough quote range.