Fixed Price vs Hourly Rate: Which Is Best for Your Project?

Fixed price vs hourly rate comes down to one question: who pays when the work takes longer than planned? On a fixed price, the developer carries that risk and charges for it through a buffer, while on an hourly rate (often called time and materials in contracts) you carry it yourself but only pay for the hours actually worked. Fixed price suits work you can describe precisely, hourly suits work you can't, and for most larger projects the best deal is a mix: a fixed-price discovery phase followed by fixed-price phases, fixed sprints or capped hours.

I'm a freelance developer based in Denmark, and I start larger projects with a paid, fixed-price discovery phase, so I'm not neutral here. I've tried to be just as clear about when that setup is the wrong fit for you.

The short answer: which model fits which project

Here's my rule of thumb. If you can write down what "done" looks like and how you'll test it, the work can be priced fixed. If you can't yet, pay for the clarification first or buy hours with a cap.

The pricing model is only one part of the budget. For typical ranges by project type, see my guide to software development cost.

Where the risk sits in each model

Every software quote starts with an estimate of hours. A fixed price is calculated the same way. The difference is who's left holding the bill when the estimate turns out wrong, and there are three kinds of risk to think about, plus a fourth if you hire across borders.

Estimate risk

An estimate is a guess about something that hasn't been built yet, and the uncertainty is highest at the start. On hourly billing, you pay for the extra hours. On a fixed price, the developer does, which is why any sensible developer adds a buffer. You pay that buffer even when the project runs exactly to plan. Think of it as insurance: the premium is the same whether or not anything goes wrong.

Change risk

This is where many buyers get caught out. A fixed price only covers what's written down. New ideas, or discovering that something needs to work differently, become change requests with their own price. On hourly billing, changes are easy, but every one draws on the same budget.

So in both models you pay for changing your mind. A fixed price just makes it visible.

Quality risk

Each model gives the developer a financial incentive you should know about. On a fixed price, the developer earns more the faster the job is done, so testing, documentation and cleanup can get squeezed when hours run short. On hourly billing, there's no financial pressure to finish quickly.

Most developers work properly either way, but the contract should protect you. On a fixed price, that means clear acceptance criteria (a written description of how you'll test that something is done) and a period where bugs are fixed free of charge. On hourly billing, it means a weekly update with hours used and what they went on.

Currency and contract risk across borders

If you hire a freelancer in another country, the currency and the contract terms add risk of their own. A fixed price is only fixed in its own currency, so a quote in GBP or USD isn't fixed for a eurozone business. Agree on the invoicing currency and which country's law applies before you sign, whatever model you choose.

What the buffer in a fixed price really costs

The buffer rarely shows up in a quote, but it's there, and its size varies by developer and by job. Here's a worked example, with numbers for illustration only.

Say a job is estimated at 200 hours. At €100 an hour excluding VAT, that's €20,000. The rate is a round number to keep the math simple, and you can check real ranges in my post on what Danish freelance developers typically charge. Add a 25% buffer for a fixed price and the quote becomes €25,000.

A fixed price works in your favor when the job overruns by more than the buffer. Two things pull the other way, though.

The vaguer the scope, the bigger the buffer, because the developer has to cover themselves. And when a fixed-price project overruns badly, there's almost always an argument about what the contract actually included. The last row in the table is rarely as calm in real life as the number suggests.

A fixed price pays off most when the scope is so well described that the buffer can be small. That's also when hourly billing is most predictable. The choice matters most on unclear projects, and there the answer is rarely a pure model.

How I combine fixed-price discovery with hours or sprints

The setup I usually recommend splits the project by how much is known. Each part gets the pricing model that matches its uncertainty.

1. Fixed-price discovery

A short, clearly bounded phase where the goal, key features, integrations and risks get written down, and you get an estimate for the rest. Uncertainty is highest here, but the work is small and has a clear end, so it can be priced fixed without a big buffer. The material should be yours afterwards, so you can also use it to get quotes elsewhere. Typical prices and contents are in my post on what a discovery phase costs.

2. The build, in the model that matches what you know

After discovery, there are usually three options:

• Fixed price per phase fits when part of the work has become concrete, such as login, user roles and an integration with a well-documented API like Stripe. The developer carries the estimate risk, and you carry the change risk.
• Fixed sprints fit when the product needs shaping as you go. A sprint is a fixed period, for example two weeks, at a known price. You decide what goes to the top of the list, and you can stop after any sprint. The price per period is fixed, but you carry the risk of how much gets done. It's the same thinking as the fixed budget with flexible scope I describe in agile vs waterfall.
• Capped hours fit when tasks are small and hard to predict, such as adjustments after your first users try the product. A cap isn't a fixed price. It means the developer stops and checks with you before going over, so you never get an invoice you didn't approve.

3. A retainer after launch

Once the product is live, tasks get smaller and less predictable. A monthly retainer or a block of prepaid hours fits better than a fixed price for every small change. I cover how to set one up in the guide to developer retainer agreements.

When each model is the wrong choice

None of the models is always right. These are the situations where each one tends to cost you money.

When hourly billing doesn't fit

• When the budget is locked, for example because a board, an investor or a grant program approved a set amount and you need to know exactly what you'll spend.
• When nobody on your side has time to follow along. Hourly billing needs someone to check hours each week and set priorities.
• When you don't know the developer yet. Without trust, every invoice becomes a discussion. Start with something small and well-defined.

When a fixed price doesn't fit

• When you're building something new that users haven't tried before. You'll learn as you go, and every lesson becomes a change request.
• When the scope can't be described precisely yet. You'll either pay for a large buffer or get a narrower product than you expected.
• When the work is ongoing, such as bug fixing and small improvements. Quoting every small task takes nearly as long as doing it.

When the phased mix is overkill

A small job of 10-30 hours doesn't need a discovery phase. A short description and an estimate are enough, or a small fixed price straight away.

And if you need a binding fixed price on a large project without spending time on discovery first, I'm not the right fit. A larger agency that can absorb a big risk, and prices it accordingly, is more realistic.

Questions that expose the risk in a quote

Two quotes in different models can't be compared directly. A €25,000 fixed price and a €20,000 estimate tell you nothing until you know what happens if the estimate runs over. Ask these before you sign:

If you already have several quotes on the table, my guide on how to compare software development quotes shows how to line them up fairly.

Next steps

Start by answering one question honestly: can you describe what "done" looks like and how you'll test it? If yes, ask for a fixed price with acceptance criteria. If not, pay for discovery first, or buy capped hours with a weekly update.

My pricing page shows how I price discovery phases and builds. You own the code from day one, you talk directly to the person writing it, and you'll hear back within one business day.

Frequently asked questions

Is time and materials the same as hourly billing?+

Mostly, yes. Time and materials means you pay for the hours worked plus any direct costs, such as licenses, hosting or third-party services. Some suppliers bill the hours by the day instead of by the hour. Ask whether there's a cap, how often you'll be invoiced, and whether direct costs are passed on at cost or with a markup.

Is a day rate better than an hourly rate?+

Neither is better: they're the same model in a different unit. Day rates are common for contractors in the UK and for longer engagements where the developer works several days a week on your project. Before comparing quotes, convert to the same unit and check how many hours count as a day, since it varies between suppliers.

Can you switch from a fixed price to hourly mid-project?+

Yes, if both sides agree. It usually happens at the end of a phase: the delivered work is accepted and paid at the fixed price, and the rest continues as capped hours. Switching in the middle of a phase is harder, because it's unclear how much of the fixed price has been earned. Agree up front that the model can be revisited at each phase.

Are bug fixes included in a fixed price?+

Bugs in what was agreed should be fixed at no extra cost. New requests or changed behavior aren't bugs, and that's where most disagreements start. Get it in writing how long the developer fixes bugs for free and how you'll tell a bug from a change. If a lot is at stake, have a lawyer review the contract. This isn't legal advice.