billable.devHourly vs Fixed-Price for Developers
By Mark Fulton · 2026-08-08 · 5 min read
Every freelance developer eventually has the hourly-versus-fixed-price argument, usually with themselves, usually at proposal time. Both models are fine. Both are also traps in the wrong situation. The useful question isn't "which is better" — it's "who is carrying the risk on this project, and are they being paid for it?"
What each model actually is
Hourly means the client buys your time. Scope can move, priorities can shuffle, and the meter keeps running. The client carries the estimation risk: if the work takes longer than anyone hoped, they pay for the difference.
Fixed-price means the client buys an outcome. You quote a number for a defined deliverable, and the estimation risk moves to you: if it takes twice as long, you eat the difference. In exchange, you get to price the outcome rather than the hours — which is where the upside lives.
Everything else people say about the two models is a consequence of that risk transfer.
| Hourly | Fixed-price | |
|---|---|---|
| Client buys | Your time | An outcome |
| Estimation risk sits with | The client | You |
| Scope changes | Absorbed, billed | Renegotiated |
| Your upside from working faster | None — you bill less | Full — efficiency is margin |
| Your downside from underestimating | None | You eat it |
| Needs a written scope | Helpful | Load-bearing |
| Cash-flow shape | Steady, predictable | Lumpy, milestone-driven |
| Fails when | Client wants budget certainty | Scope was never pinned down |
| Invoice must show | Detailed line items, hours | Milestone matching the proposal |
Where hourly wins
Hourly is the right default when the work can't be pinned down in advance:
- Maintenance and support. "Fix whatever breaks this month" has no definable scope; hourly (or a retainer, which is hourly with a floor) is the honest structure.
- Legacy codebases. Estimating work in a codebase you've never seen is guessing. The first weeks in any inherited system are archaeology, and archaeology bills hourly.
- Clients who iterate. If the client changes direction weekly — common with early-stage founders — fixed-price turns every change into a renegotiation. Hourly makes iteration frictionless because they're paying for exactly what they redirect.
- Open-ended collaboration. Embedded work with a team, code review, advising. There's no deliverable, so there's nothing to fix a price to.
Hourly's weakness is well known: it caps your income at hours worked and quietly punishes you for being fast. The developer who fixes something in one hour bills less than the one who takes six. You can partially offset that with a higher rate — speed and experience justify one — but the structural ceiling remains.
Where fixed-price wins
Fixed-price works when the deliverable is genuinely definable:
- Well-scoped builds. A marketing site from an approved design. A documented API integration. A migration with a clear before-and-after. You've done similar work before and your estimate has a real basis.
- Repeatable work. The third time you build the same kind of thing, your actual cost drops and your price doesn't have to. Fixed-price is how efficiency becomes margin instead of a discount.
- Clients who need budget certainty. Some organizations simply cannot buy "hourly, we'll see." A fixed number gets approved; an open meter doesn't.
The failure mode is equally well known: scope creep. Fixed-price without a written scope is a donation. The price only protects you if the deliverable's boundary is explicit — what's included, what isn't, and what happens when something new appears ("happy to add that; it's out of the original scope, so I'll quote it separately").
A useful discipline: build the fixed price from an internal hourly estimate, add a risk buffer (20–40% depending on uncertainty), and never share the hours math with the client. You're selling the outcome; the estimate is your private cost model.
The hybrid most experienced devs land on
In practice, many freelancers converge on a blend:
- Discovery phase, fixed and small. A paid, fixed-price week to explore the codebase or spec the project. This converts the biggest unknown — "what is this project, really?" — into a deliverable, and it makes the estimate for the main work honest.
- Well-defined builds, fixed. Priced from experience, buffered for risk.
- Everything ongoing, hourly or retainer. Maintenance, iteration, support.
This maps price to risk on each piece of work instead of forcing one model onto all of it.
The cash-flow consequence nobody mentions
There's a second axis that gets ignored in this debate, and it matters more for solo operators than the risk argument does: fixed-price billing is lumpy.
Hourly work produces a steady stream of similar-sized invoices. Fixed-price produces a few large ones tied to milestones, with gaps between them — and if a milestone payment slips, you have no partial coverage. The JPMorgan Chase Institute's study of 597,000 small businesses found the median one holds just 27 cash buffer days — under a month of expenses without inflows. A single late milestone payment on a fixed-price project is roughly the entire buffer of a typical small business.
Which is the practical argument for the hybrid: keep some hourly or retainer work running underneath the fixed-price projects, so a slipped milestone is a problem rather than a crisis. And whichever model you pick, the terms and follow-up sequence in getting paid on time do more for your cash position than the model choice does.
What it means for your invoices
The billing model changes what your invoice has to communicate.
Hourly invoices live or die on the line items. The client is paying for time they can't see, so the descriptions carry the trust: what was done, when, how long. Vague hourly invoices are the single biggest generator of awkward client questions. This is where itemizing from your actual work history shines — your commit log already contains the "what" and the "when," and turning your git log into line items makes the invoice write itself. Billable's line items have a per-item hourly toggle for exactly this: hours × rate shown transparently.
Fixed-price invoices are simpler — one line per milestone, matching the proposal wording — but the milestone description still matters, because the person approving payment needs to connect it to the agreement without asking.
Either way, the mechanics of a clean invoice are the same, and we've covered them in what belongs on a software development invoice. If you want to skip straight to producing one, the generator is free and runs entirely in your browser.
A decision rule that mostly works
If you can write the deliverable in two sentences that both you and the client would sign, fixed-price it — with a scope boundary and a buffer. If you can't, bill hourly and itemize well. And if a client pushes for a fixed price on work neither of you can define, that's not a pricing question; it's a scoping problem wearing a pricing costume. Sell them a paid discovery phase instead.