Fixed Price vs Hourly: How to Pay for Software Development
Fixed price and hourly contracts move risk in different directions. Here is how each one works, where each fits, and a middle option that suits most projects.
When you hire a developer or a studio, the contract type shapes the whole project: how changes are handled, who carries the risk, and how much time goes into arguing about scope. This article compares the two common models and describes a third that works well for most products.
How each model works
Fixed price: you agree on a scope and a price before work starts. The developer delivers that scope for that price.
Hourly (also called time and materials): you pay for the time spent. Scope can change as you learn.
Who carries the risk
This is the real difference between the two.
| Fixed price | Hourly | |
|---|---|---|
| Work takes longer than expected | Developer absorbs it | You pay for it |
| You change your mind | Requires a change request | Simple to accommodate |
| Budget certainty | High, if scope holds | Lower |
| Upfront planning needed | A lot | Little |
| Incentive for the developer | Finish within the estimate | Keep you satisfied enough to continue |
Under a fixed price, the developer protects against overruns by adding a margin to the quote and by holding you to the written scope. Under hourly billing, you carry the risk of overruns, and in return you can change direction freely.
When fixed price fits
- The scope is small and well understood, such as a marketing site or a defined integration
- Requirements are unlikely to change during the build
- You have a hard budget limit and need certainty more than flexibility
- You can describe what "done" means in writing
When hourly fits
- You are building something new and expect to learn as you go
- The work is ongoing: maintenance, improvements, support
- You are adding to an existing codebase whose condition is unknown
- You want to adjust priorities from week to week
The problems with each
Fixed price
- Scope arguments. Any request outside the written scope becomes a negotiation. This consumes time and goodwill.
- Padding. The risk margin is built into the price, so you pay for problems that may never occur.
- Pressure on quality. When the budget runs short, the easiest savings are the ones you cannot see, such as tests and error handling.
Hourly
- No ceiling. Without limits, costs can drift well past what you planned.
- You have to manage it. You need to review progress and decide what is worth the time.
- Trust is required. You are relying on the developer to work efficiently.
A middle option: fixed price per milestone
Most product work fits neither model cleanly. A practical alternative is to split the project into milestones of one to three weeks and fix the price of each one separately.
- Each milestone has a small, clear scope, so the estimate is accurate
- You can change direction between milestones at no cost
- You never commit more than a few weeks of budget at a time
- You see working software at the end of each milestone, which tells you whether to continue
This gives you most of the certainty of fixed price and most of the flexibility of hourly billing.
What to put in the contract either way
- Ownership. You own the code, designs and data once each invoice is paid.
- Payment schedule. Tie payments to delivered work.
- Change process. How a change is requested, priced and approved.
- Acceptance. How long you have to review a delivery, and what counts as accepted.
- Warranty. A period after delivery in which defects are fixed at no charge.
- Exit. How either side can end the contract, and what is handed over.
How to choose
Ask yourself two questions:
- How confident am I in the scope? If you can write it down and expect it to hold, fixed price is reasonable.
- How much do I expect to learn during the build? If the answer is "a lot", choose hourly or milestones.
For a first version of a new product, milestones are usually the best fit.
Summary
Fixed price buys certainty and costs you flexibility. Hourly buys flexibility and costs you certainty. Pricing each milestone separately lets you keep a good share of both.
A clear brief makes any of these models work better. See how to write a software project brief, or tell us about your project and we will propose a structure that fits it.