TL;DR: Fixed price works when the scope is small, well understood and unlikely to change, because the risk of being wrong is low and both sides can price it. Time and materials works when the scope is uncertain or will change as you learn, because you pay for the work actually done instead of a padded guess. For most custom software, the safest structure is neither in its pure form: a short fixed-price discovery or first milestone that removes the biggest unknowns, followed by fixed-price milestones or a capped time-and-materials phase for the rest. What protects you is not the contract type. It is a scope written as outcomes, a change process both sides agree on before the first change, and a way to stop early with working software in hand.
Almost every buyer asks for a fixed price, and it is easy to see why. A single number makes a budget approval simple and seems to move the risk onto the vendor. Almost every experienced vendor is cautious about giving one, and that is also easy to see, because software scope rarely survives contact with real users unchanged. Both instincts are reasonable. The trouble starts when the contract type is chosen to settle that tension instead of to fit the actual project.
Here is how the two models really behave, where each one fails, and how to structure a deal that protects you either way.
What each model actually means
Fixed price means the vendor agrees to deliver a defined scope for a defined fee. If it takes longer than expected, that is the vendor's problem. If you want something outside the defined scope, that is a change request, priced separately.
Time and materials (T&M) means you pay for the hours or days the team actually works, at agreed rates, usually billed weekly or monthly. You can change direction at any point, and you carry the risk that the work takes longer than hoped.
The real difference is not who pays for overruns. It is when the uncertainty gets priced. Under fixed price, the vendor prices it up front, as a contingency built into the number. Under T&M, you pay for it as it happens, only if it happens.
Where fixed price is the right call
Fixed price is a good fit when the vendor can estimate the work with genuine confidence. That tends to mean:
- The scope is small and concrete. A marketing site, a defined integration between two documented APIs, a well-specified feature added to a codebase the team already knows.
- The unknowns are few and named. Nothing in the project depends on an undocumented legacy system, unproven hardware or an AI model whose accuracy nobody has tested yet.
- The requirements are unlikely to move. You know what you need and you are not planning to learn your way into it.
- You need budget certainty more than flexibility. A grant, a fixed internal allocation, a board-approved number that cannot be exceeded.
When those conditions hold, fixed price is fair to both sides. The contingency in the price is small because the risk is small.
Where fixed price quietly goes wrong
The problem with fixed price on uncertain work is not that the vendor loses money. It is what the vendor does to avoid losing money.
The contingency gets paid either way. If a vendor is uncertain, the honest response is to add margin for the risk. If the risk never materializes, you paid for it anyway. On projects with real unknowns, this padding can be substantial, and you cannot see it in the quote.
Scope gets read narrowly. Once the price is fixed, every ambiguous line in the specification becomes a negotiation. "Users can export reports" can mean a CSV button or a configurable reporting engine. On a fixed price, the vendor is incentivized to build the smallest defensible reading of each line.
Learning becomes a change request. The best ideas in a software project usually arrive after users touch the first working version. Under a rigid fixed price, every one of those improvements is a formal change, with its own quote, delay and friction. Teams stop suggesting them.
Quality absorbs the overrun. When a fixed-price project runs long, the hours have to come from somewhere. The usual places are testing, documentation and the parts of the code nobody will see until it needs maintaining. That cost reappears later, often after the contract has ended.
None of this requires a bad-faith vendor. It is just what the incentives produce.
Where time and materials is the right call
T&M fits when the project's shape will be discovered rather than specified:
- You are building something new. A 0 to 1 product, where the first version exists to learn what the second version should be. We cover how to size that kind of work in what an MVP costs.
- The hard parts are uncertain. Computer vision that has to work in real lighting, the way the Raqts wall has to respond to real racquet hits. An AI feature whose accuracy depends on your data. An integration with a system that has no documentation.
- The work is ongoing. Continued development after launch, maintenance and iteration, or engineers added to your own team, which is closer to talent augmentation than to a project.
- You want to steer week by week. You have someone who can prioritize, review and make decisions quickly.
Where time and materials goes wrong
T&M has its own failure modes, and they land on the buyer.
There is no natural stopping point. Without a budget cap and a defined goal, the work expands to fill whatever the backlog contains. Each week looks reasonable; the total does not.
Visibility depends on the vendor. If you only see an invoice with hours on it, you cannot tell whether those hours bought progress. T&M without working software shown regularly is trust without evidence.
It needs someone on your side. T&M gives you control, and control needs an owner. If nobody on your team has time to review, decide and say no, the flexibility becomes drift.
The structure that usually works best
For most custom software, the answer is a hybrid that uses each model where it is strong.
1. Start with a short, fixed-price discovery
Before committing to the full build, pay for a small, fixed piece of work whose job is to remove the biggest unknowns. That might be a technical spike on the riskiest integration, a working prototype of the core flow, or a proper scope and estimate built from your real systems. It is cheap, it is fixed, and it turns the most expensive guesses into facts. A good brief makes this phase shorter, because the questions are already answered.
2. Fix the price on milestones, not the whole project
Once the unknowns are gone, break the build into milestones, each delivering working software you can use or test. Price each milestone fixed if the scope is now clear, or as capped T&M if parts are still moving. You only commit to the next milestone after seeing the last one, which limits your exposure to one milestone at a time.
3. Put the riskiest work first
Whatever the contract type, the hardest, least certain part of the project should be built first. On a product like Fyuel, an accounting platform for the fuel trade, that is the connection to ledgers and banks, not the dashboard. On the Geonode SDKs, it is getting the same behavior across every platform the SDKs target. If an estimate is going to be wrong, you want to find out in week two, not month four.
4. Agree the change process before the first change
Write down how changes are requested, estimated and approved, and what happens to the timeline when they are. A good change process makes changes cheap to discuss and easy to say yes or no to. A bad one, or none at all, turns every change into a dispute.
What protects you under either model
The contract type matters less than a few clauses most buyers never look at.
Scope written as outcomes. "Dispatchers can create a job from an email in under a minute" is testable. "Job management module" is not. Outcome-based scope reduces the arguments about what was promised, whatever the price model.
Working software on a regular cadence. You should see something that runs, not a status report, at least every couple of weeks. On every project we ship, from LectureNotes AI to the ARCortex XR builds, the early working version is where the most important decisions get made.
A clean exit at every milestone. If you stop after any milestone, you should leave with the code, the accounts, the documentation and a system someone else could pick up. We cover what that looks like in practice in software ownership and handover.
Acceptance criteria and a warranty period. Agree how a milestone is accepted, and that defects found shortly after acceptance are fixed at no charge. This is standard, and its absence is a warning sign.
A budget cap on T&M. A ceiling the vendor must not exceed without written approval, plus a forecast to completion in every update, turns open-ended T&M into something a finance team can live with.
How AI-native delivery changes the math
When a senior team works with AI coding agents, the time to build well-understood parts of a system drops sharply. That shifts the balance in two ways.
First, more of a project becomes estimable, because the routine parts are fast and predictable. That makes fixed-price milestones more realistic than they used to be. Second, the share of the project that is genuinely uncertain, the integrations, the data quality, the behavior of real users, stays roughly the same size and becomes a larger share of the remaining effort. That is the part worth paying to de-risk early. We describe how we work this way in our ship-in-days playbook.
It also means you should be skeptical of any quote, fixed or T&M, that prices the routine work as if it were hard. Ask how the estimate was built and which parts are carrying the uncertainty.
Buyer checklist
Before you sign either kind of contract, check:
- Have the biggest unknowns been named, and is there a plan to resolve them first?
- Is the scope written as testable outcomes rather than module names?
- Is the work split into milestones that each deliver working software?
- Is there a written change process with clear approval rules?
- For T&M, is there a budget cap and a forecast to completion in every update?
- For fixed price, is it clear what is excluded and what assumptions the price rests on?
- If you stop after any milestone, do you leave with everything you need to continue elsewhere?
The bottom line
Fixed price buys certainty and charges you for it. Time and materials buys flexibility and asks you to manage it. Neither is the safe choice on its own. The safe choice is to spend a small, fixed amount removing the unknowns, commit to the rest one milestone at a time, and make sure you can walk away with working software at every step. If the project is immersive, the same logic applies, with a few extra cost drivers we cover in what an XR app costs.
Weighing quotes or deciding how to structure a build? Book a demo and we'll help you find the unknowns worth fixing first, then send back a clear plan and timeline, usually within a day. See our work: Fyuel, LectureNotes AI, Raqts, Geonode, ARCortex and more.