Fixed price vs time and materials: how to choose a billing model for an IT project

Fixed price vs time and materials? A fixed price suits a project whose scope can be described before the start so precisely that at acceptance you can check whether it has been delivered. Paying for time worked suits projects where the scope will change or still has to be discovered. Most projects do not fit neatly into either category, which is why hybrid models work well in practice: a fixed price for a well-described stage and hourly billing with a cap for whatever is not yet known.

Neither model is cheaper by definition. They differ in who pays for an error in the estimate, and that is the question to start the choice with.

What really separates fixed price and time and materials

Both models have the same components: scope, working time and rate. They differ in which component is fixed in the contract and which one follows from how the project goes.

The third row matters most. Every time estimate in a software project carries uncertainty, because some problems only come to light while the code is being written. The documentation of an external API turns out to be out of date, the data to be imported is in worse shape than it looked in a screenshot, and a feature that is simple on paper has edge cases nobody thought of. The question is not whether reality will differ from the estimate, but who will pay for the difference.

Fixed price: where the buffer in the price comes from

In the fixed price model, the contractor takes on the risk that the work will take more time than it assumed. Nobody sensible takes on risk for free, so there is a buffer in the price. Its size depends on how well the scope is described. The more unknowns, the bigger the buffer, because the contractor is also pricing what it does not yet know.

A simple example shows the mechanism. The numbers are illustrative and have nothing to do with market rates. A contractor estimates a project at 300 hours, but knows from experience that with a scope described like this, similar projects have taken anywhere from 250 to 400 hours. With billing for time worked, you pay for the actual number of hours, somewhere in that range. With a fixed price, the contractor will quote closer to the upper end, because it is the one paying for every hour above the amount. If the project takes 260 hours, you have overpaid. If it takes 400, you have come out even. Before the start you do not know which scenario will happen, so you pay for certainty about the amount.

A fixed price also shapes the contractor's incentives. Every hour over the estimate is its loss, so it has an interest in interpreting the scope narrowly and finishing quickly. This is not an accusation, but a mechanism that works in honest companies too. The counterweight is a scope described as features with acceptance criteria. If it is clear what has to work and how to check it, a narrow interpretation has nowhere to hide.

The second consequence concerns changes. Every change of scope needs a separate quote and approval, because it changes the basis on which the amount was calculated. When changes come up every week, pricing them takes more time than the changes themselves.

A fixed price works best when four conditions are met at once: the scope can be described as features with acceptance criteria, the contractor knows the technology and integrations, decisions on the client side are made quickly, and you do not expect changes of direction during the project. A company website with ready copy, a landing page, an online store on a proven platform with typical integrations or a panel with a closed list of screens are typical candidates.

Time and materials: what you pay for and what you have to control

In the time and materials model, you pay for the time actually worked at an agreed rate, hourly or daily, sometimes different for different roles in the team. The contractor undertakes to work diligently, not to deliver a specific result for a specific amount. That is where the flexibility of this model lies, and where its risk lies too.

The flexibility is real. You can change priorities after the first tests with users, add a feature or drop something that turned out to be unnecessary, without annexes and renegotiation. You pay for what was done, not for a risk buffer.

The risk is real too. There is no upper limit to the amount, and the contractor's incentive is reversed, because every extra hour is revenue for it. An honest company does not drag the work out on purpose, but in the hourly model nobody apart from you has a financial reason to keep an eye on the budget. That is why time and materials requires work on the client side: reading reports, setting priorities and deciding when a feature is good enough to move on to the next one.

Five control mechanisms without which an hourly project is not worth starting:

• A budget cap with a warning threshold. For example: the contractor lets you know when usage approaches an agreed threshold, and stops work on reaching the cap until you make a decision.
• Reports broken down by task. The item "40 hours: application development" lets you check nothing. The item "6 hours: importing products from a CSV file, handling invalid rows" does.
• An estimate before any larger task. Before the team starts work on a feature, it says how long it may take, and tells you when the estimate has been exceeded.
• A list of people and rates. Who works on the project, in what role and at what rate. Any change of person happens with your knowledge.
• Visibility of the results. Access to the repository and the test version, so that the reported hours are backed by changes you can see.

The risks for both sides in each model

Each model distributes risk differently, but none of them removes it. This is how it looks in situations that come up in almost every project:

The first row deserves the attention of any client who chooses a fixed price because "the risk is on the contractor's side". A contractor that has gone over budget still has to finish the project, and the easiest place to save time is on things you do not see at acceptance: testing edge cases, documentation, tidy code. A fixed price protects your budget, but not the quality. Quality is protected by acceptance criteria and access to the code along the way.

The last row works the other way round. With hourly billing it is hard to prove inefficient work, because the contractor never committed to a specific result in a specific time. The protection is reports and caps, not a dispute after the fact.

Fixed price vs time and materials: which model when

The choice of billing model follows from a few questions about the project, not from the preferences of either side. Answer them before you start talking about the price:

For typical kinds of project, the answers fall into a repeatable pattern:

With mobile apps, the list of unknowns also includes the app store requirements and their review times. If you are still deciding whether you need an app in a store or whether a web app is enough, the answer changes the scope more than the choice of billing model. We cover this in our article mobile app or PWA.

Hybrid models: the most common answer in practice

A pure fixed price and pure time and materials are the two ends of a scale. In between are several models that combine a predictable amount with a flexible scope.

Paid discovery, then a fixed price

The first stage is analysis: workshops, a description of the features with acceptance criteria, a check of the integrations and a prototype of the most important screens. It is billed by the hour or for a small fixed amount. Only on the basis of its result does the contractor quote the build at a fixed price, now without a large buffer for unknowns, because most of them have disappeared. The result of the discovery phase should belong to you, so that you can take it to another company.

A fixed price per stage

The project is divided into stages, each with its own scope, price and acceptance. The next stage is priced only after the previous one has ended, when more is known. After each stage you can stop the project, and you have a working piece rather than half of everything. The Civil Code provides for this arrangement directly: if a work is delivered in parts and the fee was calculated for each part separately, it is due once each partial delivery has been made (Article 642 § 2 of the Civil Code).

Time and materials with a cap

Hourly billing with an upper limit on the amount for the whole project or for a stage. What matters most is what happens at the cap. If the contractor stops work and waits for your decision, it is still time and materials, with a safety fuse. If it has to finish the scope within the cap at its own cost, it is in practice a fixed price, only without the buffer in the amount, and then an honest contractor will ask for a precise description of the scope.

A fixed budget, a variable scope

The budget and the deadline are fixed, and the scope is arranged by priority: first the essential features, then the important ones, and finally the ones that would be nice to have. If something takes longer, whatever is less important drops off the end of the list. The model works well for the first version of a product, provided the priorities are set down in writing and both sides take them seriously.

A shared target cost

The parties agree a target cost and split any difference, up or down, in an agreed proportion. The contractor earns less when it exceeds the target and more when it comes in below it. The model requires full transparency about hours, and trust, so you tend to see it in large projects and long-term cooperation rather than in a first engagement.

Retainer: a fixed pool of hours for maintenance and development

A retainer is an agreement in which you pay every month for a reserved pool of the contractor's time, and in return you get its availability and an agreed response time. It is a model for the period after launch, when the system needs updates, fixes and gradual development. The agreement should answer a few questions:

• Size of the pool. How many hours a month are reserved and what they cost.
• Unused hours. Whether they lapse or roll over to the next month, and if they roll over, up to what limit.
• Hours beyond the pool. At what rate they are billed and whether they need your consent.
• Response time. Separately for an outage that stops sales and for a small fix that can wait a few days.
• Scope. What the pool covers: dependency updates, backups, monitoring, fixes, new features.
• Termination. The notice period and the obligation to hand over access and documentation at the end.

A retainer pays off when the work is regular and there is something to do every month, or when the system is so important to the company that a guaranteed response time is valuable in itself. If changes happen once a quarter, ad hoc billing for the hours actually worked will come out cheaper. What maintenance after launch covers, and what your options are once the warranty period ends, is described in our article on monitoring and maintenance after launch.

Billing model and contract type: a specific work or services

The billing model is a commercial arrangement, but underneath it sits a specific type of contract from the Polish Civil Code. It determines what happens when something goes wrong. A contract's type is not decided by its title: with contracts, what is examined is the common intention of the parties and the purpose of the contract rather than its literal wording (Article 65 § 2 of the Civil Code). Contracts in IT projects often combine several elements, for example the delivery of a specific work, the provision of services and the transfer of copyright.

A fixed price usually means a contract for a specific work. The contractor undertakes to deliver a specified work and the client to pay the fee (Article 627 of the Civil Code). The fee can be a lump sum or based on a cost estimate, and the difference matters a great deal:

• Lump sum. The contractor cannot demand a higher fee, even if at the time the contract was concluded the extent or cost of the work could not be foreseen (Article 632 § 1 of the Civil Code). A court can raise the lump sum or dissolve the contract only if, as a result of a change in circumstances that could not have been foreseen, performing the work would expose the contractor to a gross loss (Article 632 § 2 of the Civil Code). The mere fact that the work turned out to be larger is not enough.
• Fee based on a cost estimate. It rests on a breakdown of the planned work. If work not foreseen in the breakdown proves necessary along the way, the contractor can demand a higher fee. If the contractor prepared the breakdown itself, it can do so only if, despite due diligence, it could not have foreseen that work. It cannot demand a higher fee for additional work done without the client's consent (Article 630 of the Civil Code). If the increase would be significant, the client can withdraw from the contract without delay, paying an appropriate part of the fee (Article 631 of the Civil Code).

Two more provisions on specific works matter for planning. Until the work is finished, the client can withdraw from the contract at any time, but has to pay the agreed fee, less whatever the contractor has saved (Article 644 of the Civil Code). So pulling out of a fixed price project halfway through does not mean paying for half. Conversely, when the work requires the client's cooperation and that cooperation is missing, the contractor can set a deadline and withdraw from the contract once it has passed (Article 640 of the Civil Code).

Time and materials usually means a contract for the provision of services. The provisions on mandate contracts apply to such contracts accordingly (Article 750 of the Civil Code). The most important consequence: the client can terminate at any time, reimbursing expenses and paying for the work done so far, and if it terminates without good reason, it should also compensate for the damage. The contractor can also terminate at any time, and in a paid contract terminated without good reason it is liable for the damage. The right to terminate for good reason cannot be waived in advance (Article 746 of the Civil Code). For the client this is flexibility, but also the risk that the team will walk away mid-project. That is why the notice period and the obligation to hand over the project matter so much in an hourly contract.

How to protect yourself in a fixed price contract

With a fixed price, a dispute is almost always about one question: was something in scope. The contract should settle it before it comes up.

• Scope in an annex. Features described so that their delivery can be checked, and a list of things excluded from the price.
• Pricing assumptions stated explicitly. For example: "integration via the supplier's documented API, with access to a test environment provided by the client", "the client supplies copy and photos by an agreed date". If an assumption turns out to be wrong, the contract says what happens next instead of leaving it to negotiation.
• Change procedure. A change request, a quote of its impact on the amount and the deadline, and approval in an agreed form before work starts.
• Payments after stage acceptance. Each instalment tied to something that can be checked, for example acceptance of a working basket on the test version.
• A deadline counted from an event. From signing the contract, from the deposit or from the delivery of materials, with a rule for moving it when the delay is on your side.
• Rights to the code from every paid stage. So that stopping the project after the second stage does not leave you with code you cannot use.
• Settlement if the project is stopped. Article 644 of the Civil Code gives you the right to withdraw, but at the price of the full fee minus the contractor's savings. The contract can set out a simpler method, for example payment for the accepted stages and for documented work in the current stage.

What to look for when choosing the contractor itself, and which copyright clauses have to be in the contract, is described in our article how to choose a software house.

How to protect yourself in a time and materials contract

With hourly billing, a dispute is usually about whether the hours were needed. The contract should give you tools to react along the way rather than challenge an invoice after the fact.

• A budget cap and a warning threshold. For the whole project and for stages, with an obligation to stop work at the cap until you decide.
• Rates per role and the rules for changing them. How often, and with how much notice, the contractor can change its rates.
• Reports and a deadline for objections. How often you get a statement, how detailed it has to be and how much time you have to dispute an item.
• Team composition. Who works on the project, whether a change of person needs your consent and whether the time it takes to bring a new person up to speed is billable.
• Estimates before larger tasks. An obligation to give an estimate and to report when it has been exceeded.
• Notice period and handover. Since the law allows a contract for services to be terminated at any time, agree a reasonable notice period for both sides and what the contractor hands over at the end: code, documentation, access.
• Rights to the code for every billed period. In the hourly model there is no single final acceptance, so the rights should pass, for example, every month, after payment for that period.

What protects the contractor, and why that is your business too

A contract that shifts all the risk onto one side is rarely cheaper for the other. A contractor that is asked to sign a fixed price with unlimited revisions, penalties only on its side and payment of the whole amount after acceptance will build that risk into the amount, refuse, or protect itself in other ways, for example by interpreting the scope narrowly. Several clauses that protect the contractor are therefore in the interest of both sides:

• Payment terms. In commercial transactions, the payment term cannot exceed 60 days from delivery of the invoice, unless the parties expressly agree otherwise and the arrangement is not grossly unfair to the creditor. When a large business is paying and the creditor is a micro, small or medium-sized business, the 60-day limit applies without exception (Article 7 of the Act on Counteracting Excessive Delays in Commercial Transactions).
• The consequences of late payment. Without having to send a demand, the creditor is entitled to statutory interest for late payment in commercial transactions and to compensation for the cost of recovering the debt: the equivalent of EUR 40 for amounts up to PLN 5,000, EUR 70 for amounts above PLN 5,000 and below PLN 50,000, and EUR 100 from PLN 50,000 (Article 10 of that Act).
• The client's cooperation. Deadlines for delivering materials, access and decisions, with the rule that the contractor's deadline moves by the waiting time.
• Acceptance when there are no objections. If the client raises no objections within the agreed period, acceptance is deemed to have taken place. Without this clause, a project can get stuck in limbo.
• A liability cap. For example up to the value of the contract. Such a cap has its limits, though: a clause stating that the debtor will not be liable for damage it may cause the creditor intentionally is void (Article 473 § 2 of the Civil Code).

Example: one surprise in three models

Take an order handling panel integrated with invoicing software. In the third week of work, it turns out that the software's API does not support invoice corrections, although the documentation suggested otherwise. A workaround has to be built, which will take extra time. This is how the same situation plays out in three models:

None of these scenarios is bad. The only bad one is where the contract does not say who decides and how, and the answer has to be negotiated under deadline pressure.

Frequently asked questions

Which billing model is cheaper?

Neither, by definition. With a fixed price you pay for a risk buffer, and with billing for time worked you pay for the actual time, which may be shorter or longer than the estimate. With a well-described scope, the difference made by the buffer is small. With a lot of uncertainty, a fixed price is either high or unrealistic.

Does a fixed price guarantee the deadline?

Not automatically. The deadline in a contract for a specific work also depends on the client's cooperation, for example on delivering materials and decisions on time. If the contract does not say how the deadline is counted while the contractor is waiting for you, the guarantee of the deadline is weaker than it looks.

Can time and materials have a maximum budget?

Yes. That is the capped model: you pay for the actual hours, but only up to an agreed amount. Agree on what happens at the cap: whether the contractor stops work and waits for your decision, or finishes the scope at its own cost. That decides whether it is still hourly billing or already a fixed price.

Can the billing model be changed during the project?

Yes, and it often makes sense. A typical example is a fixed price for the first version and a switch to hourly billing or a retainer after launch, when further development begins. It is worth making the change at the boundary between stages, after acceptance, so that it is clear what was settled under the old model.

Where to start the conversation about the model

Before you ask a contractor for a price, answer the five questions from the section on choosing a model and attach the answers to your project description. You will then see straight away whether the contractor's proposal follows from them.

Whatever the model, at the end of the project you should get the rights to the code and documentation that allows another team to take the system over. With us, that is a standard part of every project. How the cooperation works, from the first message to launch, is described on our How we work page, and you can find the scopes of our services on the offer page. If you want to talk about which billing model fits your project, write to us via the contact form.