When you commission custom software, one of the first decisions is how you'll pay for it: a fixed price agreed upfront, or time and materials billed as the work happens. Fixed price vs time and materials software contracts sound like a procurement detail. They aren't. The model you choose decides who carries the risk when — not if — reality diverges from the plan, and that single choice shapes budget, flexibility, quality, and how the whole relationship feels. We walk clients through this trade-off constantly as a custom software developer, and the honest answer is that neither model is "better" — they're tools for different jobs.
Here's the tension worth sitting with before you pick. A landmark McKinsey–Oxford study of more than 5,400 large IT projects found they run, on average, 45% over budget and 7% over time while delivering 56% less value than predicted (McKinsey). Software is genuinely hard to predict. Your contract model doesn't remove that uncertainty — it only decides who holds it and what you pay for the privilege.
Fixed price locks scope, timeline, and total cost before work begins. You agree on exactly what will be built and what it costs, and the vendor owns the risk of delivering it within that number. You buy certainty — and pay for it in rigidity.
Time and materials (T&M) bills you for the actual hours worked at agreed rates, plus materials or markup, with no fixed total. The US Federal Acquisition Regulation, which defines the model for government contracting, is blunt about its nature: a T&M contract "provides no positive profit incentive to the contractor for cost control" (FAR 16.601). You buy flexibility — and take on the job of governing it.
Here's the head-to-head before we dig into each.
Dimension | Fixed Price | Time & Materials |
Who owns the risk | Vendor, within scope; you own change-order risk | Shared; you carry scope and budget risk |
Budget predictability | High — known upfront | Lower — depends on hours (tame it with a cap) |
Flexibility to change | Low — changes are formal, costly change orders | High — re-prioritize anytime |
Speed to start | Slow — needs a full spec first | Fast — start before every detail is settled |
Management overhead | Front-loaded (spec + change negotiation) | Ongoing (timesheets, burn tracking) |
Quality incentive | Risky — margin protected by cutting corners | Aligned on quality, not on speed |
Cost transparency | Low — real costs hidden in the quote | High — visible hours, rates, and burn |
Best-fit project | Small, well-defined, stable scope | Evolving, discovery-driven, long-term |
Fixed price feels safe because the number is fixed. But look at where that certainty comes from. To commit to a firm price on an uncertain build, a vendor has to price in every risk they can imagine — and pad for the ones they can't. You pay that risk premium whether or not the risks materialize. Certainty isn't free; it's bundled into the quote.
Then there's the incentive problem. Once the price is locked, the vendor's margin is protected mainly by spending less on your project. That pressure shows up as junior staff on the work, "we'll add testing later," and no budget for the refactoring that keeps software maintainable. None of it is visible in the quote, and all of it is yours to live with afterward.
Finally, fixed price handles change badly. Anything not in the original spec becomes a change order — a mini-negotiation that's slow, sometimes adversarial, and priced at the vendor's leverage rather than the market's. And change is nearly guaranteed: PMI found 52% of projects experience scope creep (PMI, Pulse of the Profession 2018). A model that makes change expensive and frictional is fighting the normal life of a software project.
None of this makes fixed price wrong. It makes it right for a narrow, important set of projects — which we'll get to.
Under T&M you pay for real work at real rates, and you can see exactly where the money goes: hours, roles, and burn rate, week by week. That transparency is the model's biggest strength. You can add a feature, drop one, or re-sequence the roadmap without renegotiating a contract, which is why T&M is the natural fit for agile delivery and for anything with genuine discovery in it.
The weakness is the flip side of the same coin. Because there's no fixed total and, as FAR notes, no built-in incentive for the contractor to control cost, an ungoverned T&M engagement can drift into a blank check. Vendors often add a markup on materials and pass-through costs, commonly in the 15–35% range, on top of labor. The answer isn't to avoid T&M — it's to govern it, which is easier than it sounds and which most of this article's hybrid section is about.
Strip away the contract language and the choice comes down to one question: how well-defined and stable is the work? The clearer and more fixed the scope, the more a fixed price makes sense. The fuzzier and more evolving it is, the more T&M protects you from paying a huge risk premium for certainty the vendor can't actually deliver.
That's why the same research that indicts big projects also favors iterative delivery. The Standish Group's CHAOS data (2011–2015) found agile projects succeeded about 39% of the time versus 11% for waterfall, with waterfall failing outright nearly three times as often (via InfoQ). Treat those figures as an industry survey rather than audited data — Standish's raw numbers are proprietary — but the direction is consistent with everything else: locking a full scope upfront correlates with worse outcomes on non-trivial work, and fixed-price contracts require exactly that lock.
Say you're building a customer portal, and you believe it's roughly a $200,000, five-month build.
Under fixed price: you invest weeks in a detailed spec so the vendor can quote. They come back at $250,000 — the extra $50K is the risk buffer for everything they can't see yet. Three months in, you learn your users need a feature nobody anticipated. It's a change order: $30,000 and a three-week delay, negotiated while the clock runs. You end near $280,000, and the parts that got squeezed to protect margin surface as maintenance cost next year.
Under T&M: you start in two weeks with a prioritized backlog instead of a frozen spec. You see burn every week. When the new feature emerges, you simply add it to the next sprint and drop a lower-value item to hold the budget. You land around $210,000 — but only because someone on your side watched the burn and made the trade-offs. Without that governance, the same flexibility could have carried you well past $250,000 with nothing forcing the trade-off.
Same project. The "safe" fixed price cost more and flexed worse; the "risky" T&M cost less but demanded active management. That's the trade in miniature.
The fixed-versus-T&M framing is a false binary. The models most experienced buyers actually use sit in between, and this is where a good partner earns their keep:
Capped T&M (not-to-exceed): the flexibility of T&M with a hard billing ceiling the vendor can't exceed without your sign-off. Add a burn alert — say, written escalation at 75% of budget — and you get most of T&M's upside with much of fixed price's protection.
Fixed-price discovery, then T&M build: price a bounded discovery and scoping phase as a fixed fee, because its output is well-defined, then build on T&M using that spec as the plan. This is the pattern we recommend most often — it puts a fixed price exactly where it works and T&M exactly where it works.
Fixed-price MVP, then T&M scale: lock the first releasable slice, ship it, then move to T&M for iteration once you're learning from real users.
Phased fixed price: re-scope and re-price at each phase boundary, so each phase is quoted against known information instead of guesses.
Per-sprint ceiling: cap the cost per sprint to bound risk while staying fully agile.
The common thread: you don't have to accept a single risk posture for the whole project. You can put certainty where you have it and flexibility where you don't.
This is the most common question we get, and the answer is: sort of, if you fix the right variable. Traditional fixed price fixes scope and lets cost flex through change orders. The smarter move on evolving work is to fix the budget and timeline and let scope flex — you commit to spending $200K over five months and deliver the highest-value features that fit, re-prioritizing as you learn. You get budget certainty without pretending you can specify everything upfront. It's less a fixed-price contract than a capped, outcome-focused engagement, and it fits how modern software is actually built. It also depends on real delivery discipline, which is where broader CodeStringers capabilities matter more than the contract wording.
Score your project on five questions:
How clear is the scope? Fully specified, or still emerging?
How likely is it to change? Stable, or evolving as you learn?
Is it routine or novel? A bounded integration, or genuine product discovery?
How long is it? A short one-off, or a long-term build?
Can you govern a T&M engagement? Do you have someone to watch burn and make trade-offs?
Clear, stable, short, routine → fixed price fits. Fuzzy, evolving, long, novel → T&M (ideally capped) fits. Partly known → a hybrid, usually fixed-price discovery then a capped-T&M build.
And watch for red flags either way: a vendor quoting a firm fixed price off a one-page brief is padding heavily or planning to change-order you later; a T&M proposal with no cap, no burn reporting, and no cadence is a blank check. The same trade-offs show up in adjacent contract choices — our take on fixed-bid vs. cost-plus contracts covers a related decision, and the true drivers of custom-software cost sit underneath all of it.
Before you ask anyone to quote, be honest with yourself about how well you actually understand what you're building. That single judgment — clear and stable versus fuzzy and evolving — points you at the right model more reliably than any contract template. When in doubt, buy a small fixed-price discovery first; it's the cheapest way to turn "fuzzy" into "clear" and to price the rest honestly.
If you want help making that call on a specific project, that's exactly what we do at the start of an engagement. Book a free consultation and we'll look at your scope, tell you honestly which model — or hybrid — fits, and structure it so the risk sits where it belongs rather than where it's easiest to hide.
By the CodeStringers Team — Zoho Experts & Custom Software. CodeStringers is a custom software engineering firm writing from work we've actually shipped for clients.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
How to Choose a Software Development Company: A Buyer's Framework (article)
Cost Plus vs Fixed Price Contract: Which Should I Use? (article)
Software Maintenance Costs, Explained: What You'll Actually Pay After Launch (article)
A time and materials contract bills the hours each role works in a period, usually every two weeks or monthly, at the rates agreed in the contract, plus any pass-through costs such as licences or hosting. A good vendor sends a timesheet by person and task with each invoice, and a burn report that compares spend to date against the estimate. If you are not getting both, ask for them, because they are the only way to govern the engagement.
A not-to-exceed clause names a ceiling the vendor cannot bill past without your written approval, states what happens when the cap is reached, and sets an alert point, commonly at three quarters of the budget, where the vendor must raise it. It should also say whether the cap covers the whole project or each phase, and whether unused budget rolls forward. Without the alert and the approval step, a cap is just a number on a page.
On paper the vendor does, because the price is fixed. In practice the risk comes back to you in other forms: a junior team, skipped testing, a narrow reading of the specification, or a project that stalls while the vendor asks for more money. A bid that is far below the others is a warning, not a bargain. Ask the low bidder to walk through their estimate line by line before you sign.
Put both on the same basis. Ask the fixed price vendor for the hours and rates behind the number, and ask the time and materials vendor for a realistic range, not a single figure. Then compare scope: a fixed bid often excludes items the other quote includes, such as data migration, training or post-launch fixes. The fair comparison is total expected cost for the same scope, with the risk premium and the governance effort made visible.
Under a fixed price contract, a warranty period after acceptance usually covers defects against the agreed specification at no charge, but anything outside the specification is a change order. Under time and materials, bug fixes are billed like any other work, which is why the quality of testing during the build matters more. In both cases, write down what counts as a defect, how long the warranty lasts, and who decides.
Yes, and it is more common than people expect. The usual trigger is a stream of change orders that shows the original specification no longer describes the work. The cleaner route is to close out the fixed phase at a defined milestone, agree what has been delivered and paid for, and start a new statement of work on time and materials with a cap. Switching without a formal close leaves both sides arguing about what the old price covered.
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
