Why your freelance developer should quote fixed price, not hourly (and how to get them to)

When you hire a freelance developer hourly, you’re paying them to take longer. That’s the math. Every extra hour they spend on your project is more money in their pocket. Even ethical developers feel that pull subconsciously — and unethical ones milk it on purpose.

Fixed-price contracts flip the incentive. Once the price is locked, the developer’s incentive is to ship fast and well, because anything else cuts into their margin.

Yet 80% of freelance development engagements still happen hourly. Here’s why, and how to get out of that trap.

Why hourly happens (and why it’s a bad sign)

Hourly contracts persist for three reasons:

1. The client doesn’t know what they want. If you can’t write a clear brief, the developer can’t quote fixed price. They protect themselves by switching to hourly.
2. The developer can’t estimate. Junior devs and devs new to a tech stack honestly can’t predict how long things take. Hourly is their safety net.
3. The developer prefers it. Hourly hides slow work. Senior devs who insist on hourly when the scope is clear usually have a reason — and it’s usually not in your favor.

If you’ve written a solid brief and the developer still won’t quote fixed price, that’s a yellow flag. Two solid briefs in a row that get hourly quotes? Run.

What a developer needs from you to quote fixed price

Most failed fixed-price negotiations come down to the brief, not the developer. Send them this list before the discovery call:

1. The success metric (one sentence)

Not “I want a better website.” Not “I want users to sign up.” Try: “I want the signup conversion rate on /pricing to go from 1.2% to 2.5% within 60 days of launch.”

A measurable, time-bounded, single-number goal is the foundation of every fixed-price quote. Without it, scope creeps the moment the developer thinks “but what if they meant…“.

2. The hard constraints

• Tech stack you require (or are willing to change).
• Browsers / devices you must support (still IE11 for a Korean government contract? Say so).
• Compliance: GDPR, SOC 2, HIPAA, PCI-DSS.
• Deadline: hard or soft, and why.
• Budget: the band, not the ceiling.

Don’t hide budget. A good developer will design the scope to fit it; a bad one will inflate the quote to whatever they think you’ll pay.

3. The “must have” vs “nice to have” split

For every feature you want, mark it M or N. A good rule: fewer than 50% of the items should be M. If everything is M, your scope is too big for a fixed quote.

When you write the brief, the M list becomes the contract. The N list goes in a “phase 2” or gets dropped if the M list eats the budget.

4. The existing-code map

If you have an existing codebase, list:

• The languages and frameworks
• Where the source is (private GitHub? Bitbucket? “On my old laptop”?)
• Who else has touched it recently
• What’s currently broken

Nothing detonates a fixed-price quote faster than discovering on day 3 that the existing code is a tangled WordPress with 47 custom plugins.

What the developer should give you in return

A solid fixed-price quote has six things. If any are missing, push back.

1. Line items. Not “Build the app — €5,000”. A real quote breaks down per workstream so you can negotiate or trim items.
2. A timeline with milestones. Not “4 weeks”. Try: “Week 1: setup + auth shipped. Week 2: dashboard. Week 3: payments. Week 4: QA + launch.”
3. An explicit out-of-scope list. What is NOT included. This is the developer’s protection against creep, and your protection against assuming things you didn’t pay for.
4. A change-request process. “Anything not on the M list goes through a change request, quoted separately.” This is the explicit safety valve for both of you.
5. Payment terms. Common: 30% on signing, 30% at milestone 2, 40% on delivery. Some devs prefer 50/50. Anything that asks for 100% up-front from a freelance dev you don’t know is a scam.
6. An end date for support. Most reasonable: 30 days of free post-launch bugfixes, then retainer or per-fix billing.

Four red flags that the quote is bad

1. No line items. Pure number. You can’t negotiate what you can’t see.
2. No out-of-scope list. Means everything you ask for becomes “yes but more money.”
3. Project management buffer is more than 20%. They’re padding because they don’t trust their own estimate.
4. No payment milestones. Asking for 100% up-front, or 100% on delivery. Both extremes are red flags from opposite directions.

How I do it

I send a fixed-price quote within 48h of the discovery call. The quote has line items, a milestone-based timeline, an explicit out-of-scope list, a change-request process, and 30/30/40 payment terms. The first 30% becomes non-refundable on day 1; the rest is refundable until each milestone is signed off.

That’s it. No hourly trap. No surprise invoices.

If that’s the kind of contract you want, send me a brief and I’ll have a quote in your inbox tomorrow.