Quick answer

Fixed price works best when the scope is genuinely well defined — you know what "done" looks like before work starts. Hourly (or milestone-based with flexible scope) works better when requirements are expected to evolve, such as early-stage product discovery. Milestone-based fixed pricing with a written scope — what I quote by default — captures most of the benefit of both: predictable cost per phase, with room to re-scope between milestones.

Fixed price: predictable, but only as good as the scope

A fixed-price quote protects the client from cost overruns — if the scope is accurate. The catch: a fixed price is only as reliable as the scope document behind it. Vague scopes lead to disputes over what counts as "in scope" the moment a requirement turns out to be more complex than expected.

Fixed price works well for well-understood work: a landing page, a defined feature, a known integration. It works poorly for exploratory product work where nobody — including the founder — fully knows the requirements yet.

Hourly: flexible, but exposes you to scope creep

Hourly billing is honest about uncertainty — you pay for time spent, and the developer is not penalized for unexpected complexity. The risk shifts to the client: without disciplined scope management, hourly billing can run longer (and cost more) than expected with no natural stopping point.

Hourly works best paired with short, regular check-ins and a running estimate — not as an open-ended retainer with no visibility into progress.

The middle ground: milestone-based fixed pricing

Breaking a project into milestones, each with its own fixed-price scope, combines predictability with the ability to adjust direction between milestones based on what you learn. This is the default model I quote: a scoped first milestone (often the core workflow), then subsequent milestones scoped once the product direction is clearer.

ModelBest forMain risk
Full fixed priceClearly defined, stable scopeScope disputes if requirements shift
HourlyExploratory or evolving requirementsCost overrun without discipline
Milestone-based fixedMost MVP and product buildsRequires a written scope per milestone

What I would do

I would scope the first milestone in writing with a fixed price, ship it, then scope the next milestone once real usage or feedback is in hand. This avoids both the trap of a huge fixed-price quote based on guesses and the trap of an open-ended hourly engagement with no checkpoint.

Common mistakes

Signing a fixed-price contract for genuinely exploratory work and then fighting over scope the moment reality diverges from the plan. Accepting open-ended hourly billing with no milestone checkpoints or running estimate. Choosing a pricing model based on what sounds safer rather than what actually matches the project’s certainty level.

Decision checklist

  • Scope certainty assessed honestly before choosing a pricing model
  • Written scope document exists for any fixed-price milestone
  • Hourly engagements have regular check-ins and a running cost estimate
  • Milestone boundaries and "done" criteria defined in writing

FAQ

Is fixed price always cheaper?

Not necessarily — a fixed price for uncertain scope often includes a risk buffer. Milestone-based fixed pricing on well-defined chunks is usually the most cost-predictable approach.

Does hourly billing mean less accountability?

Not if paired with regular check-ins and a running estimate. The risk is specifically open-ended hourly billing with no visibility into progress.

What pricing model do you use?

Milestone-based fixed pricing by default — a scoped first milestone, then subsequent milestones scoped once direction is clearer.

How is scope defined before a fixed-price quote?

A written brief covering goals, in-scope and out-of-scope items, and what "done" looks like for that milestone — this becomes the reference point if questions come up mid-build.

Related guides

Related services

Want a clear Next.js / full-stack quote?

For US, UK, and Australia founders — see packages & pricing, Hire full-stack / freelance full-stack developer, or start a project brief.

Related: Services & pricing · Hire full-stack / freelance full-stack developer · FAQ · all resources