Short answer: use a fixed price when the scope can be written down with testable acceptance criteria, which covers most first releases after a short discovery. Use time and materials when the work is exploratory, depends on systems nobody has inspected yet, or is an ongoing product where priorities change monthly. Most projects that go well use a hybrid: a small paid discovery, a fixed-price first release, then a monthly arrangement for iteration.
How each model works
Fixed price
The vendor quotes one price for a written scope, usually paid in milestones. If the work takes longer than estimated, the vendor absorbs the difference. If it takes less, the vendor keeps it. Because the vendor is carrying that risk, the price contains a margin for it, and because the price is tied to the scope, anything outside the scope needs a change request.
The model depends entirely on the quality of the scope document. "User management" is not a scope. "An admin can invite a user by email, assign one of three roles, and deactivate the account; deactivated users cannot log in" is.
Time and materials
You pay for time actually worked at agreed rates, usually invoiced every two weeks or monthly, plus any agreed pass-through costs. The vendor provides an estimate, not a promise. You can reprioritize at any point without paperwork, and you stop paying when you stop the work. The cost of that freedom is that the total is open-ended unless you add controls: a budget cap, timesheets you can inspect, and a regular report of budget used against progress.
A monthly retainer or dedicated team is a form of time and materials: a fixed amount of capacity per month instead of hours counted individually. That model is compared with the other two in the guide to how outsourcing a build works in practice.
Who carries which risk
| Risk | Fixed price | Time and materials |
|---|---|---|
| The work was underestimated | Vendor | Client |
| The scope was incomplete or ambiguous | Disputed: the vendor reads it narrowly, the client broadly | Client, but without dispute: the missing work is simply done and billed |
| Requirements change after learning something | Client, through change requests | Client, through a longer engagement |
| A third-party API or legacy system behaves badly | Vendor, unless listed as an assumption | Client |
| The team is slow or inefficient | Vendor | Client, unless monitored |
| Quality is cut to protect margin | Client, unless acceptance criteria and review catch it | Lower: no incentive to rush |
| Work expands to fill the budget | Lower: no incentive to add hours | Client, unless capped and reported |
| Client is slow to give feedback | Vendor bears the idle cost, so contracts add response deadlines | Client pays for the waiting or the context switching |
Neither column is safe by default. Fixed price moves the estimating risk to the vendor and creates a quality and rigidity risk for you. Time and materials removes the incentive to cut corners and creates a budget risk for you. The controls you add should match the column you chose.
Side-by-side comparison
| Fixed price | Time and materials | |
|---|---|---|
| What you need before starting | A detailed scope with acceptance criteria | A goal, a prioritized backlog and a budget |
| Budget predictability | High for the agreed scope | Low unless capped |
| Flexibility | Low; changes are priced one by one | High; reprioritize whenever you like |
| Price for identical work | Slightly higher; includes a risk margin | Slightly lower; you carry the risk yourself |
| Time to start | Slower: the scope must be written and agreed first | Faster |
| Your involvement | Heavy before the build, lighter during it | Continuous: you steer every week |
| Administrative overhead | Change requests, milestone acceptance | Timesheets, burn reports, invoice review |
| Typical payment pattern | Milestones tied to accepted deliverables | Periodic invoices for time worked |
| How it fails | Arguments over what the scope meant; vendor resists every change | The budget runs out before the product is usable |
Hybrid models
Paid discovery, then fixed price
A short engagement at a fixed fee produces the things a reliable fixed price depends on: a feature list with acceptance criteria, core user flows or a clickable prototype, a technical plan and a list of assumptions. The build is then quoted against that document. You own the output and can take it to any vendor. This is the most reliable way to get a fixed price that does not collapse into disputes, and it lets both sides test the working relationship cheaply. A clear project brief with ranked features shortens the discovery and sometimes removes the need for it.
Fixed-price first release, then a retainer
Version one has a definable finish line, so it suits a fixed price. After launch the work becomes a stream of fixes, small improvements and experiments driven by user feedback, and pricing each one separately wastes everyone's time. A monthly engagement with agreed capacity fits better. At BBR that ongoing arrangement is the product engineering service, and ongoing support is scoped separately from the initial build.
Capped time and materials
You pay for actual time up to a ceiling, also called a not-to-exceed estimate. If the work finishes early you keep the saving. The cap needs three supporting terms to mean anything: the scope the cap applies to, a written warning when a set share of it is used, and a rule that changes to the scope adjust the cap in writing.
Fixed price per phase or per sprint
Large or uncertain projects can be cut into phases of four to eight weeks, each with its own scope and price, agreed shortly before it starts. You get predictability within each phase and a natural point to change direction or stop between them. The risk is that nobody commits to a total, so ask for a non-binding estimate of the whole at the start and track against it.
Shared-risk variants
Some contracts set a target cost and split any overrun or saving between the parties, or discount the rate for hours above the estimate. They align incentives well and are harder to administer. They make sense on larger engagements where both sides have the patience to track them.
Decision rules by project type
| Project | Usually the better fit | Why |
|---|---|---|
| MVP with a written feature list | Fixed price, after a brief or short discovery | The finish line is definable and the founder's budget is usually hard |
| Idea that is still vague | Paid discovery first | Nothing can be priced honestly yet |
| Product in the market with a changing roadmap | Monthly engagement or T&M | Priorities shift with user feedback; change requests would dominate |
| Taking over or rescuing an existing codebase | Fixed-fee audit, then T&M or phased fixed price | Nobody can estimate code they have not read |
| Research-heavy work such as a new AI feature | Time-boxed T&M with a cap | The outcome is uncertain; you are buying learning, not a deliverable |
| Integration with an undocumented or legacy system | T&M for the integration, fixed for the rest | The unknown sits in one place; isolate it |
| Small, well-defined addition to an existing product | Fixed price | Cheap to specify, easy to accept |
| Maintenance and support | Monthly retainer | Volume is unpredictable per week and steady per quarter |
Three questions settle most cases:
- Can you write acceptance criteria for at least 80% of the work today? If yes, fixed price is available to you. If not, either run a discovery or accept T&M.
- Is your budget a hard ceiling? If yes, you need a fixed price or a cap, and you need to be ready to cut scope instead of adding money.
- Do you have time to steer weekly? T&M without an engaged client drifts. If you cannot give it a few hours every week, a fixed scope with milestone reviews suits you better.
How change requests work under each model
Under fixed price
A change is anything not covered by the agreed scope, including a feature you now understand differently. The usual procedure:
- You describe the change in writing.
- The vendor replies with the effect on price and schedule, and sometimes a cheaper alternative.
- You approve or decline in writing before any work starts.
- The approved change is appended to the scope, so acceptance still has a single reference document.
Two practices keep this from becoming adversarial. First, hold back a contingency of 10–15% of the budget for changes, because some are certain to come. Second, agree that changes can be swaps: adding something of similar size while removing something not yet built, with no price change. The contract should also state whether estimating a change is free. The contract clause checklist covers the wording to look for.
Under time and materials
There is no formal change request: you move the item up the backlog and the team does it next. The discipline that replaces it is visibility. Every new item should get a rough estimate before work starts, and the regular report should show what was added, what it displaced, and the revised forecast for reaching the goal. Without that, a T&M project absorbs twenty reasonable additions and misses its launch date with nobody having decided to miss it.
Bugs are not changes
Under either model, behavior that contradicts the agreed acceptance criteria is a defect and is fixed at the vendor's cost during the build and the warranty period. Behavior that matches the criteria but that you now want to be different is a change. Most disputes about change requests are disputes about this line, which is one more reason to write criteria that can be tested.
Warning signs in a quote
In a fixed-price quote
- A price delivered without questions. Nobody can fix a price for software they have not discussed. The number is either padded heavily or will be recovered through change requests.
- Scope described in one paragraph or as a list of nouns. "Admin panel, messaging, payments" is not something either side can accept against.
- No exclusions and no assumptions. Every honest estimate has both. If they are not written down, they will appear later as disagreements.
- A total far below the others. Compare the scopes line by line. Usually something is missing: testing, the admin area, store submission, deployment.
- Large payment up front, the rest on dates. Payments should follow deliverables you can inspect, not the calendar.
- No change procedure, or a punitive one. Either the vendor has not planned for change or plans to profit from it.
- No acceptance procedure or warranty period. "Done" is then whatever the vendor says it is.
In a time and materials quote
- Rates with no estimate at all. An estimate is not a promise, but refusing to give one means nobody has thought about the size of the work.
- No reporting commitment. You should receive time by person and task, and budget used against progress, at least every two weeks.
- Unnamed team or a single blended rate that hides seniority. You should know who is working and at what level.
- Minimum monthly hours with a long notice period. Reasonable in moderation; a way of locking you in when it is not.
- Resistance to a cap or to a time-boxed first phase. A team confident in its estimate will usually accept one.
- Billing for fixing their own defects without any distinction between rework and new work. Ask how rework is handled.
When you have proposals in hand, the list of questions to put to an agency includes what good answers on pricing and assumptions sound like. For a sense of whether the totals themselves are plausible, see how to work out an MVP budget from effort and rates, and for the broader service these models apply to, custom software development at BBR.