When a business hires a team to build software, the contract sets how it pays. Under a fixed price, the scope and the price are agreed before the work starts. Under time and materials, the business pays for the hours actually worked. The difference is who pays for surprises: the developer under a fixed price, the client under time and materials.
What a fixed-price contract is#
A fixed-price contract sets the scope, the price and usually the deadline before work starts. The developer is paid the agreed amount whether the work takes more hours or fewer.
The client pays for that certainty: a developer who carries the risk of a wrong estimate usually builds that risk into the price. Every change to the scope becomes a change request: a new estimate, a new price, sometimes a new deadline. So a fixed price works best when the scope can be written down in detail before the work starts.
What a time and materials contract is#
Under a time and materials contract, the client pays for the hours worked at agreed rates, plus the actual cost of materials: third-party licenses, paid services, hosting. US federal procurement rules describe it the same way: labor hours at fixed hourly rates and the actual cost of materials, for work whose extent or duration cannot be estimated accurately in advance.1
The scope can change from week to week without a new contract. The client carries the risk instead: if the work takes longer, the bill grows.
Control comes from how the work is run. The client sets the priorities, the invoices show where the hours went, and a budget ceiling (a not-to-exceed amount), for example a monthly one, can be agreed when the client needs one. The contract should then say what happens when the hours reach it.
Fixed price vs time and materials, side by side#
| Fixed price | Time and materials | |
|---|---|---|
| Who pays for a wrong estimate | The developer | The client |
| Known before work starts | The total price and usually the deadline | The rates and an estimate that can change |
| A change to the scope | A change request: new estimate, new price | A new priority for the next week |
| What has to be ready first | A detailed written specification | A clear first goal |
| How the spend is controlled | The price in the contract | Regular invoices, priorities, an optional ceiling |
| Fits best | A defined stage with written acceptance criteria | Integrations, a moving scope, work after launch |
When a fixed price works#
A fixed price fits when three things are true:
- The scope is written down: the screens, the rules, and what counts as done for each part.
- The work depends little on outside systems the developer does not control.
- The client needs one number for the budget.
We use a fixed price only for a defined stage of a project, one the specification describes in full. The stage is split into acceptance milestones, and each milestone has written criteria for what counts as done. The client accepts each milestone against those criteria.
When time and materials works#
Time and materials fits work whose size shows up only once it starts:
- Integration work. Connecting a CRM, accounting software or a supplier's system depends on what that system allows, and its limits often appear only during the work.
- A scope that is still moving. The first version of a tool often changes what its users ask for next.
- Work after launch: new rules, new reports, small features.
We bill this kind of work hourly and invoice monthly, so the client sees what was spent each month.
Why most projects use both#
A project rarely fits one model from start to finish. The parts that can be specified can be priced as fixed stages. The parts that cannot are better billed as time and materials. Discovery is the step that decides which part is which.
This is the order we work in:
- Usually, a paid discovery, priced before it starts. It opens with an audit of the system and process the client already has. A small project close to work we have done before can start without it.
- A written specification: what to build, what it will cost and in what order. The document is the client's whether or not we build it.
- Then either a fixed price for each stage the specification defines, or hourly billing for integration work and anything where the scope moves.
An example: one project, both models#
Take a hypothetical manufacturer that wants dealer orders priced as they are entered. One way the work could split:
- Discovery maps how orders arrive and how each product is priced, and ends with a specification.
- The order entry screen and the pricing rules are fully specified, so they become a fixed-price stage. Its milestones might be product setup, order entry and printing, each with written acceptance criteria.
- Connecting the accounting software and the largest dealer's ordering app depends on what those systems allow, so that work is billed hourly.
- After launch, new product lines and reports are billed hourly as they come up.
The client knows the price of the part that could be specified, and pays as it goes for the parts that could not.
What to put in either contract#
Whichever model you choose, the contract should say:
- what counts as done, in writing, for each milestone or deliverable;
- how a change is requested, estimated and approved;
- how often invoices come and what each one shows;
- who owns the code, the data and the documents.
A fixed-price contract also needs a list of what is out of scope. A time and materials contract also needs the rates, a ceiling if the budget requires one, and how hours are reported.
Where to start#
If you have a project in mind and are not sure which model fits it, start with a free 30-minute call. We will talk through which parts of it look clear enough to price in advance and which are better billed hourly. A price you can budget on comes once the scope is written down.
Sources
-
Federal Acquisition Regulation 16.601, Time-and-materials contracts. https://www.acquisition.gov/far/16.601 ↩
