Fixed price vs. time and materials gets framed as a preference. It is really a question about who carries the risk of the unknown, and the answer should follow from how much is genuinely unknown.
Fixed price
What it transfers: the risk of the work taking longer than expected moves to the vendor. Federal rules describe a firm-fixed-price contract the same way: it places maximum risk on the contractor. You get a number you can budget against.
What you pay for that: a premium, and it grows with how much is still unknown. Any competent firm prices the uncertainty in, because they are the ones absorbing it.
How it fails: when scope was not properly defined, fixed price turns adversarial. Every clarification becomes a change-order negotiation, the vendor is incentivized to deliver the minimum defensible interpretation, and both sides end up arguing about what a sentence meant three months ago. The relationship degrades precisely when you need it working.
Use it when: scope is genuinely settled — which in practice means after a paid discovery phase produced a specification you both signed.
Time and materials
What it transfers: nothing. You carry the risk, and you pay for what happens.
What you get for that: flexibility, and no incentive for the vendor to cut corners to protect a margin. Also, usually, a lower total when things go well, because you are not paying the uncertainty premium.
How it fails: without a cap and a cadence, it is an open tab. Projects drift, scope expands conversationally, and nobody notices until the invoices do not stop. That is why federal acquisition rules require a ceiling price on time-and-materials contracts.
Use it when: the work is genuinely exploratory, or you have an ongoing relationship and a track record.
The structure that works most often
Neither, exactly. Three parts:
- Fixed-price discovery. A defined fee for a defined output: workflow map, data profile, specification, and a firm build estimate. Small enough to approve easily, and you own the output — if you take it elsewhere, it still has value.
- Phased build with a cap per phase. Time and materials in mechanism, but each phase has a ceiling and a deliverable. You can stop at any phase boundary.
- A change process in writing. Not to prevent changes — you will want some — but so each one has a stated cost and schedule impact before it is agreed.
This gives you budget predictability without the adversarial dynamic, and gives the vendor room to raise problems rather than absorb them silently.
Change orders are the real battleground
Whichever model you pick, the arguments will be about changes. Agree the mechanism before you need it:
- Define what counts as a change versus a clarification of existing scope. The gray zone here is where relationships fail.
- Require cost and schedule impact in writing before work starts on it — not an invoice afterwards.
- Keep a phase-two list and put things on it freely. Most "changes" are genuinely good ideas that simply do not belong in this phase.
- Set a threshold below which small changes are absorbed on both sides. Negotiating every hour poisons the working relationship for very little money.
Terms that matter more than the model
- A demo every two weeks. Working software, not status reports. This single term prevents more overruns than any pricing structure.
- Your repository from day one. Not delivered at the end.
- A defined warranty period, with the distinction between defect and enhancement written down, and a plan for application support after the warranty.
- An exit clause. What you receive if you stop: code, documentation, credentials, and a handover. Cheap to agree at the start, impossible later.
The warning sign in either model
A firm that gives a confident fixed price in the first meeting, before seeing your data or the systems they must integrate with, is either padding heavily or has not understood the project. Both end badly. A serious response is a range, the assumptions behind it, and a proposal to narrow it through discovery.
More on getting comparable proposals in our guide to writing an IT statement of work that gets usable bids, and on the wider process in how government agencies actually buy software.
Our custom software engagements are structured exactly this way, for these reasons.
Comparing two proposals on different models? We are happy to look.