Fixed milestones vs hourly billing: which pricing model actually protects your budget?
Neither model is safe on its own. What protects a budget is scope that gets priced before anyone opens an editor, and only one of these two forces that.
Every founder asking this question is really asking a different one: what stops this build from costing three times what I planned?
The honest answer is that a billing model by itself stops nothing. An hourly contract can stay on budget. A fixed price can be padded or blown up by scope creep. What changes your exposure is how much work gets committed before anyone has to name a price and show you something that runs.
That is the real difference between the two models. Fixed milestones make you define the chunk and price it. Hourly billing lets the chunk stay undefined for as long as everyone is comfortable, and comfort is expensive.
| Criterion | Fixed milestones | Hourly / time and materials |
|---|---|---|
| Who carries estimate risk | The builder | You |
| Cost known before work starts | Yes, per milestone, agreed up front | No, it accrues |
| Exposure to fat-tailed overruns | Capped at the current milestone | Unbounded |
| Cost risk assessed before kickoff | Required, you cannot price what you cannot describe | Optional |
| Progress visibility | A demo at each milestone | Timesheets |
| Handling mid-build scope change | Requires re-scoping and repricing the next milestone | Absorbs change immediately |
| Best fit | A defined outcome with a launch date | Open-ended maintenance and research |
| Verdict | Fixed milestones win on budget protection. Hourly wins on flexibility. Neither wins if the milestone is too big to demo soon. | |
The risk is in the tail, not the average project
A peer-reviewed study in the Journal of Management Information Systems analyzed 5,392 IT projects completed between 2002 and 2014, worth $56.5B in 2015 dollars. Cost overruns did not cluster around a tidy average. They followed a power-law distribution with a fat tail of extreme overruns. The authors' plain conclusion: IT projects are far riskier in terms of cost than normally assumed by decision makers.
Then it gets sharper. Because the distribution is fat-tailed, the study reports that the average cost overrun for IT projects does not exist, in the sense that it cannot be calculated. There is no stable number to plan against.
That one line kills the most common budgeting habit in software. Taking an hourly estimate and adding a contingency buffer assumes there is an average overrun to buffer against. There is not. So the question is not which model is cheaper on a normal project. On a normal project they are close. The question is which model contains the abnormal one.
About a third of projects land on budget
The same paper cites U.S. Department of Defense reporting for the fiscal year ending 2020: $37 billion in IT project spending, and only 35% of projects came in within budget.
That is an organization with more procurement rigor than any startup will ever have. If two out of three of their projects miss the budget, the assumption that yours will land inside an open-ended hourly estimate is optimism, not planning.
Under hourly billing, missing the budget is simply a longer invoice. Under fixed milestones, missing the estimate on a scoped piece of work is the builder's problem, because the price was agreed before the work started.
Price the risk before the work starts
The study's practical recommendation is not a contract type. It is a sequence: realistically assess and mitigate the cost risk of a new IT project up front.
That is exactly what scoping into priced milestones forces both sides to do. You cannot put a number on a milestone without first describing what ships, deciding what is out, and admitting which parts are unknown. The estimating discipline is a side effect of the pricing discipline.
Hourly billing skips that step by design. You can start Monday with a vague brief and a rate card. It feels faster on day one, and it postpones the only exercise the data says protects you.
Fixed price does not mean waterfall
The usual objection is that fixed pricing means a frozen spec and no iteration. It does not.
Agile authority Mike Cohn has written about exactly this: a fixed-price project locks down both the delivery date and the features delivered by that date, and teams can still work in an agile way inside that constraint. Fixed pricing and iterative delivery are not opposites.
In practice that means short milestones, working software at the end of each one, and feedback that shapes what comes next. What is fixed is the commitment for the piece in front of you, not the whole future of the product.
The middle ground: caps and checkpoints
There is more than two options. Hybrid contract structures sit between the extremes:
- Capped time and materials, which bills like hourly work but sets an upper limit on how much the client will have to pay.
- Agile fixed price, which sets the budget after an initial checkpoint phase instead of demanding an exhaustive spec on day one.
Both exist for the same reason. Pure hourly leaves the ceiling undefined, and pure fixed price asks for certainty before anyone has learned anything. If you are being offered straight hourly for a build with a real budget limit, asking for a cap or a checkpoint is a reasonable counter.
Where hourly billing is the right call
Hourly is not a trap. It is the right shape for work where the deliverable genuinely cannot be named in advance:
- Ongoing maintenance and support with no fixed end state.
- Exploratory research where the goal is to learn something, not to ship something.
- Staff augmentation, where you are buying capacity into a team you already run.
In those cases a fixed price is fiction, and you pay a premium for certainty nobody can provide. The failure mode is using hourly for a first launch, where you do have a defined outcome, a budget limit, and a date that matters.
Where fixed milestones go wrong
A fixed price can hide the same risk it claims to remove. Watch for three things.
Milestones that are too big. A single twelve week milestone with one demo at the end is an hourly contract wearing a costume. You find out too late to steer.
A change process that does not exist. Scope will change. If there is no honest mechanism to re-scope and reprice the next milestone, the change gets absorbed badly or turns into an argument.
A price with no named deliverable. If you cannot read the milestone and say exactly what will be on screen when it is done, the number is not protecting you. It is just a number.
How we price work at to1 Labs
We scope projects into fixed milestones with clear pricing before the build starts, so you know what ships and when. Then you get regular demos until the product is live. No timesheets to audit, no surprise invoice at the end of a month you cannot picture.
Our contact form asks for a rough budget range rather than listing rates, with options from under $10k to $100k+. That is deliberate. The right first milestone for a $10k idea validation and a $100k product build are different shapes, and pretending otherwise is how estimates go bad.
You work directly with Alec from start to finish. No account managers, no hand-offs. We read every inbound message and reply within two business days.
Small scope, a price agreed before we start, and a demo you can click. We are not done until it is live.
- IT cost overruns follow a power-law distribution with a fat tail, and the largest study of its kind reports that an average overrun cannot even be calculated. Budgeting an open-ended engagement against an average contingency is statistically unsound.
- Rigor is not enough on its own. For the fiscal year ending 2020, only 35% of U.S. Department of Defense IT projects came in within budget, against $37 billion in spending.
- The research recommendation is to assess and mitigate cost risk before the project starts, which is precisely what pricing scope into milestones forces both sides to do.
- Fixed pricing does not mean waterfall. Locking a date and a feature set still leaves room to work iteratively inside that constraint.
- If pure fixed price feels premature, capped time and materials puts a ceiling on your exposure, and agile fixed price sets the budget after an initial checkpoint phase.
- The paper's practical recommendation is to realistically assess and mitigate the cost risk of new IT projects up front.
- Mike Cohn notes that a fixed-price project locks down both the delivery date and the features delivered by that date, yet teams can still work in an agile way inside that constraint.
- Hybrid contract structures exist: capped time and materials sets an upper limit on how much customers will have to pay, and agile fixed price sets the budget after an initial checkpoint phase rather than requiring an exhaustive spec up front.
Does a fixed price just mean the estimate gets padded?
It can, if the milestone is huge and vague. The protection comes from size, not from the number. We keep milestones small enough that each one has a named deliverable and a demo, with pricing agreed before the build starts, so you are never committing to more than the next visible piece of progress.
What happens when scope changes halfway through a build?
The current milestone finishes as scoped, then we re-scope and reprice the next one with the new information. Locking a date and a feature set for a milestone does not stop the team working iteratively inside it, so a change moves the plan forward instead of quietly rewriting the whole budget.
Is hourly billing ever cheaper than a fixed price?
Sometimes, on a project that behaves. The problem is that IT cost overruns follow a power law with a tail so fat that researchers say an average overrun cannot be calculated, and under hourly billing that tail is yours. If you want hourly flexibility with less exposure, ask for a cap on total spend or a checkpoint phase before the budget is set.