Hourly vs. Project-Based Pricing: Which Should You Use?

Worked scenarios are illustrative composites. Our editorial pen name and method.

On this page

Two ways to bill, two very different jobs

Hourly and fixed-fee pricing allocate uncertainty differently. Choose the unit after checking scope, expected effort, payment terms and who bears the cost if work expands.

The two models can produce the same invoice when hours match the estimate. Their results diverge when actual effort changes, so compare a low, expected and high time estimate for the same deliverables.

What each model actually means

Hourly means you sell time. You track the hours, multiply by your rate, and bill what you logged. If the work balloons, your pay balloons with it. If the client keeps adding “just one small thing,” the meter keeps running.

Project-based (or flat-fee) means you sell an outcome. You quote one number for a defined deliverable — “a five-page website, three rounds of revisions, $3,200” — and that number holds whether the work takes you 20 hours or 40. The client knows the cost up front. You absorb the overrun, and you keep the upside if you’re fast.

That last line is the crux. Project pricing rewards efficiency; hourly quietly punishes it. The better you get at a repeatable task, the less you earn per job on an hourly basis. It’s a backwards incentive, and worth keeping in mind every time you set a rate.

A quick scenario for each

The hourly job. A startup founder messages you on a Tuesday: “Our checkout is throwing an error, can you look into it?” You have no idea whether it’s a one-line config fix or two days buried in legacy code. A fixed fee would need a discovery stage or explicit assumptions. So you agree on, say, $75/hour, you log time as you go, and you send a short note when you cross a threshold — say, five hours — so there are no surprises. The client pays for exactly what the problem turns out to need. That’s the model doing its job: open scope, unknown depth, fair to both sides.

The project job. A bakery wants a one-page menu site — logo placement, a contact form, their hours pulled from a doc you’ve already seen. Assume you have records from comparable work. You know it’s roughly a day and a half of focused work, maybe two with revisions. You quote $1,400 flat. The owner says yes because she can drop that number into a budget. You evaluate whether the $1,400 covers the expected time and a slower-delivery case. The fee offers budget certainty for the agreed scope, while you carry the time-overrun risk.

Notice the pattern. The hourly job was a question mark. The project job was a known quantity. Almost every “which model?” argument comes down to which of those two you’re actually looking at.

The trade-offs side by side

Hourly Project-based
Who eats scope creep The client You
Who keeps efficiency gains The client You
Best when scope is Fuzzy or evolving Clear and well-defined
Client’s biggest worry “How high will this go?” “Am I overpaying for fast work?”
Your admin burden Time tracking, every session Tight estimating up front
Cash-flow feel Pay-as-you-go Often deposit + milestones
Rewards you for Thoroughness, complexity Speed, systems, expertise

Hourly terms need a shared understanding of billable tasks, reporting and any cap. Project terms need clear deliverables, acceptance criteria and a process for added scope. Both can involve client questions about time, quality and results; neither eliminates the need to communicate.

Why you need a real hourly number either way

Even if you plan to quote flat fees forever, you can’t price a project sensibly without knowing what an hour of your time is worth. A flat fee is really just an honest estimate of hours multiplied by a rate you can live on — plus an explicitly chosen allowance for uncertainty and any direct costs.

For a cost-based planning floor, add the annual business costs and compensation requirement you need revenue to fund, then divide by expected billable hours. Do not subtract hours from an income amount. The hourly rate calculator organizes those inputs; the project-pricing walkthrough shows how to apply the rate to a scoped time estimate.

One caution applies to both models, and it isn’t optional: the income you quote is not the income you keep. What you owe in tax, and how self-employment income is treated, varies a lot from one country to the next — and sometimes by region within a country. Treat every figure here as a pre-tax estimate only. Before you bank on any take-home number, check your actual obligations against your local tax authority’s official guidance or with a qualified accountant. Don’t build your pricing around a rate you haven’t run the tax math on.

The rule for choosing on each job

When a new job lands, ask one question first: can I see the finish line?

Lean hourly when:

  • The scope is genuinely unknown — debugging, “audit our setup,” open-ended consulting, “help us figure out what we need.”
  • The work is ongoing, like a retainer where tasks shift week to week.
  • The client keeps changing direction, and you’d otherwise be re-quoting every few days.
  • It’s a brand-new type of work for you, so any time estimate would be a wild guess.

Lean project-based when:

  • The deliverable is concrete enough to write down in a sentence or two.
  • You’ve done something similar before and your time estimate is trustworthy.
  • The client has requested budget certainty for a defined scope.
  • You’re fast at this particular task and want to be paid for the result, not penalized for being quick.

When a job sits on the fence — clear-ish scope, but a nervous, change-prone client — a common middle path is to scope the predictable part as a flat fee and bill anything outside that boundary hourly. Put the boundary in the agreement in plain language: “Includes X, Y, Z and two rounds of revision; work beyond this is billed at [your rate]/hour.” Define what the boundary and revision allowance mean before work starts, and it lets you hand a client the certainty they want without quietly funding their changing mind.

Record the quoted scope, actual effort, direct costs and collected fee after each job. Use those results to decide which model fits the next assignment; switching models does not by itself improve revenue or margin.

Try the matching tool