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.
| Model | Best for | Main risk |
|---|---|---|
| Full fixed price | Clearly defined, stable scope | Scope disputes if requirements shift |
| Hourly | Exploratory or evolving requirements | Cost overrun without discipline |
| Milestone-based fixed | Most MVP and product builds | Requires 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