Fixed price vs time and materials: how to choose a software contract

The two models in brief

Fixed price. You agree a scope, a price and a timeline before work starts. The vendor is paid for the result, not the hours: if the agreed scope takes longer, that is the vendor’s problem. Changes to the scope are priced and approved separately.

Time and materials (T&M). You pay for the hours actually worked, at agreed rates, usually invoiced monthly or by sprint. The scope can change at any time, and the budget follows it.

Side by side

When a fixed price works best

• The core of the product can be described. You know the roles, the main flow and the integrations, even if details will be clarified along the way.
• The budget is fixed. A founder with a seed round, a company with an approved project budget, anyone who cannot afford “it took longer”.
• You are buying a result, not a team. An MVP, a client portal, a store, a CRM for a known process.
• You want to compare vendors. Fixed quotes for the same scope are comparable; hourly estimates are forecasts nobody can be held to.

A fixed price is only as good as the scope behind it. If you are not sure how to describe yours, start with how to write a brief a studio can price.

When time and materials works better

• Nobody can describe the result yet. Research, prototypes of new technology, products whose direction changes every week.
• The work never ends. A product in active development with a backlog that is re-prioritised every sprint.
• You have strong product management in-house. Someone on your side decides what gets built next and watches the hours.
• You need people, not a project. Extending your own team with specific skills for months.

What each model hides

The hidden costs of a fixed price

• The risk buffer. A vendor who carries the risk of overruns prices it in. The less clear the scope, the bigger the buffer.
• Change requests. Every new idea costs extra and needs approval. If your scope is still moving, you will pay in change requests what you saved on the base price.
• Disputes about “done”. If acceptance criteria are vague, every review turns into a negotiation about what was promised.
• Pressure on quality. A vendor losing money on a fixed price may cut corners. The defence is clear acceptance criteria, a warranty and payment tied to accepted work.

The hidden costs of time and materials

• No ceiling. The budget is a forecast, not a limit. Projects that “just need one more sprint” are a familiar story.
• You pay for the learning curve. New people on the team, rework, meetings — all billable.
• A weak incentive to finish. Not every vendor exploits it, but the model does nothing to discourage it.
• Your management time. Someone on your side has to prioritise, review progress and check the hours every week.

Hybrids that work

The choice is not binary. Common combinations:

• Paid discovery, then a fixed price. A short, separately priced scoping phase produces the specification; the build is then priced as a fixed scope. Useful when the idea is solid but the details are open.
• A fixed price per module or milestone. The product is split into modules, each with its own price and acceptance, and later modules can be re-scoped as you learn. This keeps budget certainty without freezing the whole roadmap.
• T&M with a cap. Hourly billing with a not-to-exceed amount for each phase; the vendor must stop and ask before crossing it.
• A fixed build, then T&M support. The first release at a fixed price; changes after launch on a monthly retainer or by the hour.

Whichever model you choose, insist on visibility: under a fixed price, a module-by-module status you can check on any day; under T&M, a weekly report of hours by task. A vendor who resists either is telling you something.

The same project under both models

Take a hypothetical client portal with five modules: sign-in and profiles, orders, documents, an integration with the client’s accounting system, and an admin.

Under a fixed price, the vendor quotes the five modules and the contract fixes the total. Halfway through, the accounting integration turns out harder than expected because the old system’s export is inconsistent. The extra hours are the vendor’s problem. Then you decide you want a new report for managers. The vendor prices it as a change request; you see the cost and the extra days, and either approve it or put it on the list for later.

Under time and materials, the vendor estimates the hours for the same five modules. The integration takes twice the planned time, and you pay for every hour of it. The new report goes straight into the next sprint without a separate approval step, which is convenient, and the budget drifts by the cost of both surprises.

Neither outcome is wrong. The first gives you a known number and a formal process for changes; the second gives you speed of change and the full bill for every surprise. The question is which of those you can live with.

A quick decision guide

What makes a fixed price actually fixed

A number on a proposal is not a fixed price. These clauses are what make it one; check for them in any contract:

• The scope is split into modules, each with a description specific enough to check. Anything not in the scope is out of scope.
• “Fixed” is defined: the price does not depend on the hours spent on the agreed scope.
• A change request procedure: either side can propose a change, the vendor shows its effect on price and timeline, and nothing changes until you approve it in writing.
• Fixes are free when they bring a module in line with the scope. Revisions to meet what was agreed are not change requests.
• Acceptance is defined: how you review each module, how long you have, what counts as a defect and what happens if you don’t respond.
• Payment follows accepted work, by stages, rather than 100% upfront.
• A warranty period for defects found after acceptance.
• The rights to the code pass to you, in writing, on payment.
• What happens if the project stops: how unspent money is returned and how work in progress is handed over.

More on the payment side in milestone payments: how paying by stage protects you, and on acceptance in how to accept software.

What makes time and materials safe

If time and materials is the right model for you, the contract still needs guard rails. Look for these:

• A cap per phase or per month. The vendor stops and asks before crossing it, and you decide whether to continue.
• A weekly report of hours by task, so you see where the time goes while you can still change course, not at the end of the month.
• Named roles and fixed rates for an agreed period, and your approval before anyone new joins the team.
• An estimate before each sprint or batch of work, compared with the actual hours afterwards.
• The right to stop at short notice and receive the code, access and documentation for the hours already paid.
• Code in a repository you can see, so progress is something you check, not something you are told.

None of these turns T&M into a fixed price. They keep the budget under your control while the scope stays open.

How we work at EVA-X

We work at a fixed price. You describe the product, the estimate splits it into modules with hours and a price, and our team reviews the scope with you before a contract fixes the scope, the price and the payment schedule. In our terms, “fixed price” means exactly that: the price in a signed contract does not depend on the number of hours spent on the agreed scope, and it changes only through a change request you approve.

Payments go into the project reserve and are released module by module, only when you accept a module. To be precise about what that is: the reserve is our accounting of prepayments that have not been earned yet, shown in your cabinet as paid, released and held. It is not an escrow, trust, deposit or segregated account, and no third party holds it. If a project stops, refunds come from the unspent part of the reserve. You have 7 calendar days to review each delivered module; fixes that bring it in line with the scope are free, and defects in our code reported within 30 days of acceptance are fixed free of charge unless the contract says otherwise.

This model fits MVPs and products whose core can be described. If your project is open-ended research, a fixed price is the wrong tool, and we will say so at the team review. More on how we work: custom software development.