Fixed Price vs Hourly: Picking a Model for Small Jobs

There’s a reason developers don’t love fixed prices for vague jobs. If four hours turn into eight, they eat the difference. So any sensible freelancer adds a margin to a fixed price, and you pay for that margin whether the job runs long or not.

Neither model is cheaper in itself. What matters is who can judge the risk better: you or the developer.

Who knows the risk should carry it

When the job is clear and the developer knows the system, they can estimate well. Their risk margin is small and a fixed price suits both sides. Typical examples: an extra field on a form, a new page from an existing template, switching email sending to SMTP.

When the cause is unknown, nobody can estimate honestly. Take a bug that only shows up sometimes, in code somebody else wrote: it might take one hour to find or ten. Insist on a fixed price and you’ll either get a quote for ten hours or a polite no. Neither helps.

Most small jobs sit somewhere between. For them a combination often works best.

Criterion	Fixed price	Hourly with cap	Discovery + fixed price
Cost known upfront		cap known	after discovery
Risk margin in the price			small
Works when the cause is unclear
Changes mid-job	cost extra	easy	cost extra
Effort on your side	brief must be precise	check the timesheet	two decisions

Worked comparison: one job, three models

Suppose a developer estimates a change to a shop plugin at six to ten hours, depending on what the existing code looks like. Their rate is $100 an hour, close to the US break-even rate from our article on the freelance developer hourly rate. Every other figure is an assumption for this example.

Fixed price: upper estimate 10 h plus 10 % margin

$1,100

Hourly, if it goes well (6 h)

$600

Hourly, if it goes badly (10 h, the cap)

$1,000

Discovery 1.5 h + fixed price for remaining 6 h

$750

Range across models

$600 to $1,100

Assumed values for illustration. Real margins and effort vary by developer.

The fixed price is the most expensive option here, and the only one without surprises. Discovery plus fixed price comes out well because after ninety minutes of looking at the code, a six-to-ten-hour range turns into a firm number and the margin can shrink. Whether you’d rather pay $1,100 for certain or between $600 and $1,000 uncertain is a question about your cash flow and your nerves, not about maths.

Quote, estimate and what happens when it runs over

Words matter here. In everyday British usage a “quote” is generally understood as a firm price and an “estimate” as an educated guess, and plenty of developers use the two loosely. If you want a fixed price, write “fixed price” in the confirmation. If you accept an estimate, add a cap.

When no price is agreed at all, the law tends to fill the gap with a reasonable one. For business services in England, Wales and Northern Ireland that comes from section 15 of the Supply of Goods and Services Act 1982. Reasonable is a fine word until two people disagree about it.

Hiring a developer based in Germany? German law has a specific rule for overruns. Under § 649 of the German Civil Code, a contractor working from a non-binding cost estimate must tell you without delay once it becomes clear the estimate will be exceeded substantially. You may then terminate and pay only for the work done so far. The law doesn’t define “substantially”, which is one more reason to agree a hard cap instead of relying on a percentage.

Whatever the jurisdiction, the practical protection is the same: a written number, a written cap, and a duty to warn you before either is reached.

The fixed-price killer: changes mid-job

“While you’re in there, could you just…” is the sentence fixed prices die of. Every extra wish is a change request, and change requests are usually billed by the hour. That’s fair. It’s also how a $600 fixed price quietly becomes $1,100.

Two habits help. First, changes only in writing, with a quick estimate from the developer and your OK before they start. Second, collect extra wishes and commission them as a separate small job after the first one is signed off. Sign-off stays clean and you can see what you paid for. Our project sign-off template shows how to document it.

The best prevention is a brief with an “out of scope” line. Our guide on how to brief a developer includes one.

What an hourly invoice should show

Paying by the hour means you should be able to see what for. That isn’t mistrust, it’s normal bookkeeping. Good developers attach a timesheet without being asked.

Each entry needs a date, a duration and a one-line description a non-developer can follow. “Checkout debugging, log review” is fine. “Misc” for three hours isn’t. Ask when an item looks out of proportion. There’s usually a simple explanation, such as an unexpected clash with another plugin.

Check the billing increment too. With 15-minute increments, a five-minute call becomes a quarter of an hour. That’s common and fine when agreed upfront, but lots of short calls add up. Batch your questions into one email instead of phoning five times.

With a fixed price you don’t need a timesheet. You do need to check carefully at sign-off that every agreed point is met, because that’s usually when payment becomes due and later arguments get harder.

Sample wording for both models

For a confirmation by email, a few sentences do the job. These are examples, not reviewed contract text.

Fixed price
"For the work described above we agree a fixed price of [amount], excluding
VAT/sales tax. Changes or additional work will be agreed in writing first and
billed at [rate] per hour. Payment is due on sign-off."

Hourly with not-to-exceed cap
"Work is billed hourly at [rate] in 15-minute increments. No more than
[hours] hours will be billed without my prior written approval. If it
becomes clear the cap won't be enough, you'll let me know before it is
reached."

That last sentence is the one that counts. It puts the decision with you before the money is spent, not after.

Which model for which job

As a rough guide, not a rulebook:

For ongoing changes, see what individual tweaks tend to cost in our guide to the cost to update a website.

When many small jobs gradually turn into a product you depend on, the better question isn’t which billing model suits the next ticket. It’s whether a partner who builds and runs software for you would make more sense.

For your next job, ask the developer for a range rather than a single number. If the range is tight, take the fixed price. If it’s wide, agree a short paid discovery and ask for a fixed price afterwards.

Questions people ask

Can a developer charge more than the agreed fixed price?

Not for the agreed scope. They can charge for extra or changed work you ask for. That's why a clear list of what's included and what isn't matters so much with fixed prices.

What's a not-to-exceed clause?

It's a cap on hourly billing. The developer bills actual hours but never more than an agreed number without your written approval. If the cap looks too tight, they have to tell you before reaching it.

What if no price was agreed at all?

Then the law usually fills the gap with a reasonable or usual price. Under section 15 of the UK's Supply of Goods and Services Act 1982, for example, the customer is taken to have agreed to a reasonable charge for business services. Arguing about what is reasonable after the fact is exactly what a written price avoids.

How high should the hourly cap be?

A sensible starting point is the developer's upper estimate. If it's reached before the goal is, work stops and you decide together. You never pay more than agreed without being asked first.