Fixed price or time and materials? Software contract models

Public contracting rules draw the line clearly. Under US federal procurement rules, a firm fixed price doesn’t change with the provider’s actual costs. That places “maximum risk and full responsibility for all costs” on the provider (Federal Acquisition Regulation (FAR) 16.202-1, as of Mar 13, 2026). Under a time-and-materials contract, the buyer pays fixed hourly rates plus the cost of materials (FAR 16.601, as of Mar 13, 2026).

Germany’s model contract for public-sector software projects, EVB-IT Erstellung, offers both routes. EVB-IT are the German government’s supplementary contract terms for IT services. They describe a fixed price as a total fee that can’t be changed unilaterally and time and materials as the fee for time spent (EVB-IT general terms, version 2.0.0, Mar 2026, in German). The template is written for government agencies. In our view, it also works as an outline for companies.

The pricing model is only one building block. Our guide to SaaS explains how a SaaS project runs from idea to operations.

The numbers in the “Sources” column refer to the source list at the end of this article.

Price and deliverable are two separate questions

The pricing model doesn’t settle what the provider owes you. A provider billing time and materials can still owe a finished result that you sign off. The EVB-IT contract covers building software and still allows both types of payment (EVB-IT contract form, version 2.0.0, in German). So answer two questions separately: How will you pay? And does the provider owe a result or its working time?

In German contracts, the second question is often framed as Werkvertrag (a contract for a result) or Dienstvertrag (a contract for services). Which one applies to your project depends on what the contract says, and that’s a question for a lawyer.

Strengths: You know the total before work begins, and the risk of extra effort sits with the provider. US procurement rules name two advantages: the strongest incentive to control costs and the smallest administrative burden for both sides (FAR 16.202-1). That makes budget approval easier.

Limits: A fixed price needs a fixed scope. UK government guidance calls “fixed scope” the key component of a fixed price (UK guidance note on risk allocation and pricing, Nov 5, 2026). If the scope isn’t fixed, the UK government advises against a fixed price (UK Sourcing Playbook, Nov 5, 2026). If the description is ambiguous or incomplete, the guidance says, the provider has “wriggle room” to argue that something isn’t included in the price.

The risk premium is an estimate and can miss in either direction. If it’s too high, you pay for risks that never materialize. If it’s too low, the contract turns into a loss for the provider. According to the guidance, the provider’s focus then shifts to cutting costs, and in the worst case the contract collapses. So an unrealistically low fixed price is your risk, too.

An economic model by Bajari and Tadelis also argues against fixed prices for complex projects. Cost-plus contracts are preferred there, because changes under a fixed price trigger costly renegotiation (Bajari and Tadelis, RAND Journal of Economics, 2001). The model was inspired by private-sector construction. In our view, the logic also holds for software.

Use case: an integration with a known system, a bounded module with a written description, or a new application once discovery has pinned down its core features, roles and data. US rules require reasonably definite specifications and realistic cost estimates for this (FAR 16.202-2). Our how-to on writing a software requirements specification shows how to record the scope. Germany’s Federal Office for Information Security (BSI) already expects a requirements catalog as the basis for developing custom software (BSI, IT-Grundschutz module APP.7, in German).

Strengths: You can steer the work and change priorities. UK government guidance treats time and materials, alongside cost-plus pricing, as input-based pricing. Because the buyer carries the risks, it says such prices shouldn’t include risk premiums. It considers this approach suitable when you want to decide how the work gets done. It also says this approach can work well for pilots where neither party can predict how the requirements will evolve.

Limits: Under US rules, this contract type gives the provider “no positive profit incentive” to control costs or work efficiently. So the rules require ongoing oversight of its performance. There, the contract type is allowed only if the extent and duration of the work can’t be reliably estimated when the contract is signed, and it must include a ceiling price (FAR 16.601). The UK guidance adds that the final total is very hard to predict and that checking the bills takes time.

Time and materials takes your time. If you can’t assign someone to set priorities and review results regularly, this model is a poor fit, in our view.

Use case: a product idea that will still change with the first user tests, modernizing a legacy application whose condition no one knows in detail, and ongoing development by priority. For pilots, the UK guidance advises scaling the work to keep cost uncertainty small.

This example uses illustrative values. A provider estimates a project at 100 person-days (PD), and the scope doesn’t change. The fixed price includes a 20% buffer, the cap is 130 PD, and the target price of 110 PD splits any variance evenly, with a maximum price of 121 PD.

If the estimate holds, the fixed price in this example costs 20 PD more than time and materials. At 140 PD, it saves you 20 PD. The tipping point is 120 PD, where the extra effort equals the built-in buffer. The UK guidance recommends exactly this trade-off: if transferring a risk would cost more than the expected loss, consider keeping the risk.

A study by Flyvbjerg and colleagues shows how far estimates can miss. It covers 5,392 IT projects completed between 2002 and 2014, with estimated and actual costs available for 4,677 of them. Overruns and underruns were about equally frequent. The median ratio of actual to estimated cost was 1.0, so the typical project cost about what was planned. The average was still 1.8 times the estimate, because a few projects ran extremely far over (Flyvbjerg et al., Journal of Management Information Systems, 2022).

Small projects aren’t exempt. The concentration of outliers didn’t differ significantly between small, medium and large projects. The largest overrun hit a small workflow customization: budgeted at $1,500, it ended up costing $425,000 (in 2015 prices). The study doesn’t break down results by contract model. Our takeaway: a buffer absorbs small variances. For outliers, short phases and early checkpoints help.

Who carries the other risks?

This table reflects our assessment. Your contract may handle individual points differently.

Phased fixed price. You first commission discovery at a fixed price. Its result is the basis for the fixed price of the next phase. After each phase, you decide again. This matches the UK guidance’s point that parts of a contract can move to other pricing models once requirements are better understood. Under the name agiler Festpreis (agile fixed price), a German-language book from the publisher Hanser describes a contract model for agile projects that start with a vision or a rough specification. The term isn’t standardized. So ask what’s actually fixed: the price, the scope or the date.

Time and materials with a cap. You pay for the hours worked up to an agreed amount. What matters is what happens at the cap. Under US rules, the provider exceeds it at its own risk. Under the German EVB-IT template, the provider must deliver in full even beyond the cap. If the overrun isn’t the provider’s fault, it delivers on request for an additional fee. Without a rule like that, it’s unclear what applies at the cap. Decide whether work stops, who carries the extra cost and who makes the next decision.

Target price with shared risk. You agree on a target price and a maximum price. Both sides share variances by a fixed formula. The UK guidance describes a “guaranteed maximum price with target cost” model, in which overruns are shared equally and the maximum price in the model contract is 10% above the target price. US rules have something similar (FAR 16.403-1). The model requires open-book accounting and complex measurement. In our view, it tends to pay off on larger projects.

Fixed budget, flexible scope. Budget and timeframe are fixed, and the list of requirements is reprioritized continually. If the budget doesn’t stretch to everything, the least important items drop out. This lets you work in an agile way without leaving the budget open. When the scope exceeds cost, schedule or staffing limits, the IEEE Computer Society’s Guide to the Software Engineering Body of Knowledge (SWEBOK) names three options: reduce the scope, increase capacity or a combination of the two (SWEBOK Guide, v4.0a, Aug 2026). With a fixed budget, that leaves the scope.

A fixed price for the core with time and materials for the open parts is also possible. The EVB-IT template lets you pay for individual services separately on a time-and-materials basis.

The German EVB-IT form for change procedures (Muster 3) has three steps. The buyer describes the change it wants. The provider reviews it and, if the change affects dates or fees, submits a quote that’s binding until a set date. The buyer accepts or rejects it, and work continues on that basis (EVB-IT Erstellung, Muster 3, in German). For waterfall and other plan-based projects, SWEBOK also calls for a responsible person or group that decides on each change and for a way to notify everyone affected. According to SWEBOK, accepting a change means accepting its impact on schedule, resources or scope elsewhere in the project.

For small and mid-sized projects, we suggest this procedure:

1. Write down the change: What should change, and why? One paragraph is enough.
2. Name the impact: The provider states effort, price, schedule and the acceptance criteria affected.
3. Set an expiry date: The quote stays valid until a specific date.
4. Decide: A person named in advance says yes, no or later.
5. Record it: The change goes into the statement of work, and the total price or budget is updated.
6. Set a limit for small changes: Agree on a threshold below which changes can proceed without a request, for example half a person-day, and keep a running total.

The order and steps 3, 5 and 6 are our recommendation. Don’t start work on a change until the decision is made.

SWEBOK calls for analyzing variances between planned and actual figures, such as costs and schedules, and for spotting problems through thresholds. It doesn’t give specific values. So the following traffic light is our own suggestion:

A worked example with illustrative values: of a 100 PD budget, 40 PD have been used, or 40%. Signed off so far: 30% of the scope. The gap is 10 percentage points, so the light is yellow. If the pace stays the same, expect about 133 PD (40 divided by 0.3). The forecast helps only as long as you measure progress by sign-offs; “80% done” says little.

With a fixed price, the risk of extra cost falls on the provider. Track two other figures instead: the total of commissioned changes and the dates of signed-off milestones.

This list draws on the templates and guidance above to show what makes a quote checkable for you. It doesn’t tell you whether a contract holds up legally.

For every quote, ask for the person-days per module and the built-in buffer. The UK guidance recommends making priced-in risks visible so both sides can discuss how high they should be. For agreed assumptions, an amount is released there only if the assumption proves inaccurate. Our cost guide How much does custom software development cost? shows how to work out market prices. Which points protect you against lock-in is covered in Avoiding developer lock-in. Our how-to on choosing a software developer covers what to ask a provider before you sign.

1. Can you describe the scope with acceptance criteria? If yes, a fixed price is possible; go to question 3. If not, go to question 2.
2. Would paid discovery answer the open questions? If yes, commission discovery at a fixed price, then use a phased fixed price. If not, use time and materials with a cap or a fixed budget with flexible scope.
3. How big is the buffer relative to the risk? Ask what the premium is, and estimate how large the variance could be. If the premium is much higher, consider time and materials with a cap or a target price.
4. Can you assign someone to set priorities and review results on an ongoing basis? If yes, all models remain open. If not, time and materials is a poor fit. Choose a fixed price in short phases. Someone still has to sign off the results.
5. What happens if the project fails? The greater the damage, the more important short phases and an early checkpoint become.

Write your answers down. They’re the basis for the change procedure and for the quote checklist.