Fixed price vs time and materials, and why we sell fixed sprints
Fixed price vs time and materials is the first contract question on almost every software project, and it usually gets argued as a question of trust. It is really a question of who carries the risk that the work takes longer than anyone thought. Both models can price the same work at the same total. They differ in whose invoice moves when the estimate is wrong.
We sell fixed-price sprints, so read this knowing which side we are on. Time and materials is not dishonest, and further down is when it is the right call. But hourly billing sells you the one thing you have no interest in owning. You do not want hours. You want a working checkout, a shipped app, a feature your customers can use. Hours are what it takes us to produce those, and that should be our problem.
The two contracts, in a paragraph each
Time and materials means you pay for the hours worked at an agreed rate, plus materials such as licences, devices and hosting at cost. The scope can change on any day and the invoice follows it. If the work takes twice as long, you pay twice as much, so the risk of a bad estimate is yours.
Fixed price means a price agreed for a defined scope before the work starts. If the work takes twice as long, the vendor absorbs it. That is why a fixed price carries a premium for the risk, and why a change to the scope goes through a change request rather than straight into the work.
The names you will see in contracts
Proposals use half a dozen labels for these two models, and not always consistently. When one turns up, ask a single question: if this takes twice as long, whose invoice changes?
What each model rewards
The usual critique of time and materials is a suspicion of padding, and padding is rare. Reputable firms do not invent hours. What they do is operate inside a structure where efficiency is quietly unrewarded, and structures shape behaviour far more reliably than intentions do.
Under time and materials, an engineer who finds a way to do the job in four hours instead of twelve reduces the invoice. Nobody will admit that this affects behaviour. Over a year, across a team, it does. Not through padding, but through the absence of pressure in the other direction.
The clearest example is meetings. Billed by the hour, a status meeting is revenue. Nobody schedules one for that reason, but nobody feels the cost of it either, so the weekly sync survives long after it has stopped carrying information. Under a fixed sprint price the same meeting is an hour taken directly out of the work we committed to deliver, and it disappears within a fortnight, replaced by a written update that takes ten minutes and can be read by people who were not in the room.
The second-order effect is what happens to your attention. Under time and materials, a rational client monitors hours, because hours are what they are buying. That monitoring is itself expensive: someone on your side reads timesheets, queries line items, and forms opinions about whether a task should have taken six hours. Under a fixed price there is nothing to monitor except whether the agreed work shipped, which is visible in the repository and takes a minute to check.
Fixed price needs a fixed scope
A fixed price requires a fixed scope for the length of the sprint. That is the trade, and it is a real one. If you want to change direction on Wednesday, the change goes to the top of next week's queue rather than into the current sprint.
We are strict about this because the alternative degrades quickly. A fixed price with a moving scope is not a fixed price; it is an hourly engagement where one party has agreed not to invoice for the difference. That arrangement survives about two sprints before somebody feels cheated, and it is usually us, which then shows up as caution in the next estimate.
This sounds rigid until you notice the sprint is one week long. The longest anything waits is a few days, and in exchange the team gets a week where the target does not move. Teams that have worked with agencies on quarterly contracts sometimes expect this to be the friction point. In practice it is the part clients adapt to fastest, because a week is short enough that nothing important gets stuck behind it.
Genuine emergencies are handled separately and explicitly. A production incident on something we shipped is ours to fix immediately and is not scope. An incident on something we did not ship can be pulled into the current sprint by displacing an equivalent piece of agreed work, which is a decision you make rather than one we make for you. Both are written into the engagement rather than negotiated under pressure.
Fixed scope only feels restrictive when the sprint is long. At one week it is just a queue with a short line.
Fixed price is insurance, and it has a premium
When we estimate a sprint wrong, we finish it at the agreed price and take the loss. That happens several times a year and it is priced in, which is worth being direct about: our sprint rate carries a margin for estimation error, so on the sprints we estimate well you are paying slightly more than the raw cost of the work.
This is worth stating plainly, because the fixed-price pitch is often made as though it were free certainty. It is not. It is insurance, and you pay a premium for it in the same way you pay a premium on any other insurance. The question is whether the premium is smaller than the variance you would otherwise carry, and for a team with a runway and a board meeting, it usually is by a wide margin.
You are buying certainty and we are selling it, and certainty has a price. The alternative is that you carry the variance instead, on a project whose complexity you have less information about than we do. That is a bad trade for you even when it looks cheaper on paper.
It also does something useful to our behaviour. Because a bad estimate costs us money, the scoping call is genuinely diagnostic rather than a formality. We would rather tell you the work needs three sprints and lose the deal than agree to one and eat two.
When time and materials is the right answer
Genuinely open-ended research, where nobody can describe the finish line, is time-and-materials work, and pretending otherwise produces a bad fixed price. Emergency incident response is hourly. Long-term maintenance at unpredictable low volume is usually a retainer, which is hourly with a floor.
The test is whether the work can be described as an outcome. If you can write down what done looks like, fixed price is better for you. If nobody can, you are buying exploration, and you should buy it by the hour and keep it short.
One reasonable middle path: buy a short hourly block to answer the open question, then move to fixed sprints once the finish line is describable. We do this several times a year, usually as a two-day paid audit that converts into scoped sprints. It costs less than a badly-priced fixed engagement and less than an open-ended hourly one, which is the whole argument in miniature.
Where fixed sprints sit between the two
A fixed-price sprint is a fixed price on a short horizon. The scope is agreed for one week, priced before the week starts and not reopened until it ends. Between sprints it can change completely, as it would under time and materials. You get the certainty of a fixed price inside the week and the flexibility of time and materials across weeks, and nobody has to guess at a six-month total.
That is how our sprints work. A one-week Dev Lab sprint is $900, every lab's price is on the pricing page, and the first fourteen days are refundable. If the work turns out to need three sprints rather than one, you find out after one week and one invoice, not after the budget has gone.
