The client wants to know what the project will cost. You want to know you won't lose money on it. Between those two wishes sits the choice of pricing model: fixed price or time and materials (paying for hours worked)? That choice decides your margin more than your hourly rate does, and yet it is often made out of habit or based on what the client wants to hear. Let's look at what each option means, who carries the risk, and how to decide sensibly.
What the two models actually mean
The cleanest definitions of both models don't come from vendors' marketing copy but from the U.S. rules for public procurement, the Federal Acquisition Regulation (FAR), which has precise rules for both contract types.
Fixed price ("firm-fixed-price" in the FAR) places maximum risk on the contractor and full responsibility for all costs and the resulting profit or loss. At the same time it gives the contractor the strongest incentive to control costs and work efficiently.
Time and materials means the client pays for hours worked at fixed, agreed hourly rates (which include wages, overhead and profit) plus the actual cost of materials. The FAR adds two important points. First, this model should only be used when, at the time of signing, the extent or duration of the work can't be estimated accurately. Second, the contractor has no built-in profit incentive to control costs, so the client has to keep an eye on whether the work is done efficiently. The contract also includes a ceiling price, and anything above it is at the contractor's risk.
That leads to a simple sentence worth saying to your client too: fixed price is not cheaper, it just moves the risk to the contractor. And the contractor has to get paid for that risk somehow.
Why fixed price is a bet in software
Fixed price works when you know exactly what you're building. In software you rarely do. McKinsey and the University of Oxford analysed more than 5,400 IT projects. On average, large IT projects ran 45% over budget and 7% over time, and delivered 56% less value than predicted. According to the same study, software projects carry the highest risk of cost and schedule overruns of all IT project types.
The extremes are worse than the average. 17% of projects went so badly that they could threaten the very existence of the company. The study calls them "black swans": projects with budget overruns of more than 200%. And time works against you: every additional year a project ran increased cost overruns by 15%.
For a contractor on a fixed price this means one thing: every percent of overrun comes out of the margin. For a small software company, a single project like that can wipe out a whole year's profit. We covered why estimates go wrong so often in Software project estimation – why projects run late.
When to choose fixed price
Fixed price makes sense when:
- the scope is small and well described, ideally with acceptance criteria for every feature,
- you have built something similar several times and have your own data on how long it really took,
- the client needs a firm number for a budget or a tender and is willing to pay for the risk you take on,
- you have a clear change process: anything not in the brief is a separate order.
Without that last point, a fixed-price project quickly turns into an endless one where the contractor finishes "small things" for free.
When to choose time and materials
Time and materials is the more honest choice when:
- the requirements are still being discovered, for example for a new product or a prototype,
- the project is long and priorities will shift based on user feedback,
- it's ongoing development and support of an existing application,
- the client wants to steer priorities and decide as you go what gets done first.
The price of flexibility is trust. When the client pays for hours, they want to see what they paid for. This is where the relationship holds or breaks: without a clear timesheet, every invoice turns into an argument.
The compromise: fixed budget, flexible scope
Between the two extremes there is an option Martin Fowler describes. In his view, agile development can work with a fixed price, but not with a fixed scope. Instead of "we'll deliver these 40 features for this price", you agree differently: we have this amount to spend, we need a release by this date, and together we'll pick the best set of features that fits.
Fowler points out one more benefit: the client sees problems earlier and usually cancels sooner than on a traditional predictive project. So they don't burn the whole budget on something that doesn't work.
Combining both models works well too. Price the initial discovery and design separately, and build the proposal on its results. Or use time and materials with a ceiling price, as the FAR does: the client pays for hours but knows the maximum amount.
Five practical tips for the head of a software company
- Split large deals into smaller phases. Time works against the budget, so shorter phases with their own price lower the risk for both sides.
- Estimate from your own data, not from memory. Compare estimates with the hours actually worked on past projects.
- Track changes as separate tasks. Every extra request gets its own estimate and its own line in the timesheet, whether the contract is fixed price or time and materials.
- Share the timesheet with the client continuously, not just with the invoice. With time and materials it's the only way to keep their trust.
- Price the risk into a fixed price. If you don't have data to back the estimate, fixed price is more of a bet than a business model.
How mcptask.online helps
Whichever model you choose, you need the same thing: to know how much work was estimated and how much was actually done. mcptask.online breaks a project down into Epic → Story → Task and automatically turns each task's scrum points into an hour estimate. Time is logged straight to tasks, including from commits (a reference like "#Task-47 2h" is enough), and you can export the timesheet to JSON, CSV or PDF, for example as an attachment to the invoice. Blocker links show what is waiting on the client, so on a fixed-price project you have evidence of why the date moved.
And if you add capacity with autonomous AI developers, their hours go into the same timesheet under their own identity, just like people's.
Want estimates and hours worked in one place? Register at mcptask.online – the first 30 days are free, no credit card required.
Sources
- FAR 16.601 – Time-and-Materials Contracts, U.S. Federal Acquisition Regulation
- FAR 16.202-1 – Firm-Fixed-Price Contracts, U.S. Federal Acquisition Regulation
- Delivering large-scale IT projects on time, on budget, and on value, McKinsey & University of Oxford (2012)
- FixedPrice, Martin Fowler