Freelance Pricing That Works: A Repeatable Method

Start with what you’re really selling: outcomes, time, or risk

Freelance pricing gets easier when you’re clear about what you’re actually selling.

• Time (hours you work)
• Outcomes (results you deliver)
• Risk (how much uncertainty you’re absorbing)

Most pricing problems come from mixing these without saying so. A client hears “price,” but you might be charging for time + uncertainty + communication + revisions.

Pick one primary thing to anchor your quote:

1. If the work is predictable, sell a defined scope.
2. If the work is exploratory, sell time or smaller deliverables.
3. If the value is clear and measurable, sell outcomes.

Quick win: Before pricing, write one sentence: “I’m pricing for ___, and here’s what that includes.”

Hourly: you’re selling your time (and absorbing delivery risk)

Hourly pricing works best when you can’t fully predict the work in advance.

Great fits:

• Audits and investigations
• Ongoing support (with boundaries)
• When the client’s requirements will evolve

Watch-outs:

• Hourly can push clients to ask for “just a bit more” without realizing the cost.
• It can feel like you’re selling time, not value.

How to make hourly pricing feel fair:

• Use hourly rates + a cap (example: “up to 12 hours”)
• Define what counts as billable work
• Set expectations on turnaround time and meetings

Deliver the “hourly package” (so you’re not reinventing each quote)

For many freelancers, “hourly” becomes more profitable and easier when you add:

• A minimum (example: 2 hours)
• A range (example: 8–12 hours for the first phase)
• A revision policy (example: up to 1 round included)

Fixed: you’re selling a defined scope (and taking on risk)

Fixed pricing is powerful when the scope is clear enough that you can predict effort.

Great fits:

• Landing pages with a known layout and copy sourced by client
• A standard app feature with clear requirements
• Content deliverables with a defined outline and editing rounds

Watch-outs:

• Scope creep turns a fixed price into a loss.
• “Design updates” can mean anything unless you define it.

To protect yourself:

• List deliverables precisely
• State what’s excluded
• Define change requests and pricing for extra work

Deliverables: you’re selling pieces of value (and spreading risk)

Deliverables pricing sits between hourly and fixed.

Example idea:

• “Option A: Discovery + roadmap”
• “Option B: Landing page v1”
• “Option C: Campaign package (3 deliverables)”

Great fits:

• Creative work that comes in stages
• Projects where client decisions happen step-by-step
• Retainer-like work that still has visible outputs

Why deliverables help:

• Clients see progress
• You can price each stage based on effort and uncertainty
• You get natural “decision checkpoints” before deeper work

Choosing the right model (without overthinking it)

If you’re stuck between models, use this simple question set:

1. Can we describe the deliverable clearly enough?
   • Yes → fixed or deliverables
   • No → hourly or smaller deliverables
2. How likely are requirements to change?
   • High → hourly or phased deliverables
   • Low → fixed
3. Is the value tied to outcomes?
   • Clear → value-based can work (often as a bonus)
   • Not clear → stick to defined deliverables

A simple “model matcher” (pick one)

• Hourly: “We need to figure it out as we go.”
• Fixed: “We know what ‘done’ looks like.”
• Deliverables: “We can ship in steps, and the client will choose what’s next.”

A note on “fixed vs deliverables”

Fixed usually means one price for the whole scope.

Deliverables means one price per outcome/stage, often with decisions along the way.

If you’re worried the project might change, deliverables is often the safer first step—without locking you into endless hourly work.

Practical pricing formula for each model

Here’s a repeatable method you can reuse every time.

Step 1: Calculate your real hourly rate

Your real rate is what you need to cover:

• Direct work time
• Business costs
• Taxes
• Unpaid admin
• Risk and payment delays

Use this formula:

1. Pick how many billable hours you can realistically sell

• Example: you might work 40 hours/week, but only sell ~20–25 billable hours.

2. Estimate annual business + personal costs Include:

• Taxes (set aside a percentage)
• Software/tools
• Health insurance or other coverage
• Office costs (even if it’s just a portion of your rent)
• Professional fees and accounting

3. Add your target pay (what you want to take home)

4. Add risk buffer This covers slow months, revisions you can’t predict, and clients who take longer than expected.

Then:

Real hourly rate = (annual costs + target pay + risk buffer) ÷ billable hours

Step 2: Convert your real rate into model pricing

Hourly

• Quote: Hourly rate × estimated hours + minimum
• Add: a range and a cap where possible

Fixed

• Quote: Real hourly rate × estimated hours
• Add a fixed risk premium (even a small one helps)
• Include: what’s in scope + change policy

Deliverables

• Quote each stage separately
• Each stage gets: effort estimate × real hourly rate + small buffer

Value-based (often as a bonus)

You can keep value-based simpler by mixing it:

• Base fee for defined work
• Bonus tied to a measurable result (optional)

Example: “Base for building the page. Bonus if it hits X conversion target.”

Put the terms in writing: proposals that protect scope

A great freelance pricing system fails if your proposal is vague.

Your proposal should answer:

• What exactly are you delivering?
• How many rounds are included?
• What happens when the client asks for changes?
• When will you invoice?
• What are payment terms?

A client can’t “buy” something you didn’t define.

The pricing terms to include (every time)

Include these sections in your proposals:

• Deliverables list (with clear names)
• Timeline and what you need from the client to start (assets, access, approvals)
• Revisions policy (how many rounds, what counts as revision)
• What’s excluded (extra pages, new features, new copy, translations, additional meetings)
• Change requests (how they’re priced and approved)
• Payment schedule (milestones or start/finish)
• Acceptance (how you confirm the work is “done”)
• Cancellation/rescheduling terms (short and simple)

Scope control: define change requests before they happen

Scope creep usually starts with small, friendly requests.

Stop surprises by defining “change requests” up front.

Use language like:

• “A change request is any new requirement, new page/feature, or a revision beyond the included rounds.”
• “Change requests are quoted separately before work begins.”

A quick example: turning “design updates” into enforceable scope

Instead of saying “design updates,” specify something like:

• Included: 1 round of design revisions after the first review
• Included: adjustments to match the agreed brand colors/typography
• Excluded: new sections, new layouts, additional pages not listed in scope
• Extra: new sections/pages billed at a set rate or hourly

Now both you and the client know what “update” means.

Invoicing milestones that match how work actually ships

Milestones help you get paid while progress is happening.

A simple, common structure:

• 50% to start (covers onboarding + early work)
• 30% at first draft / first version (or after key milestone)
• 20% at delivery + acceptance

Why milestone invoicing beats “pay me after it’s done”

If you invoice at the very end:

• You carry all the cost and risk
• A delayed review can delay your payment
• Negotiation becomes harder when you’ve already done the work

Milestones keep the relationship calmer because the money timing matches the effort.

A milestone structure that works for most freelancers

Pick a structure that fits your workflow:

• Phase 1 (Start): strategy, requirements, kickoff
• Phase 2 (Build): first version / draft
• Phase 3 (Polish): revisions and final delivery

Then invoice at the moment you deliver each phase output.

Tie payment to acceptance (not “we’ll review later”)

Make acceptance clear so the last invoice doesn’t get stuck.

Use a simple acceptance rule:

• Client has X business days to review and either approve or submit change requests.
• If no response, the work is treated as accepted.

Also define what “approve” means:

• Approval of the deliverable as-is, or
• Approval with listed change requests

Make payment terms feel normal, not confrontational

Payment terms are not personal. They’re logistics.

Use standard wording like:

• “Invoices are due within 7/14/30 days.”
• “Late payments may incur a fee or suspend work after a grace period.”

If you’re worried the client will push back:

• Offer a compromise: “Net 30, but milestone 1 is required to start.”

That keeps you funded without making it a battle.

Freelance pricing sanity check: find the blind spots before you raise rates

Before you raise your rates, do a quick audit.

Ask:

• Do you spend time on admin that you’re not billing?
• Do meetings expand without notice?
• Do revisions take longer than you priced?
• Are you underestimating waiting time (reviews, approvals, feedback)?
• Are you absorbing extra risk because the scope is vague?

Then adjust your pricing by tightening scope, adding boundaries, or moving to deliverables/milestones.

Common freelance pricing mistakes (and how to correct them)

• Mistake: quoting only hours
  • Fix: add a scope checklist and revision limits.
• Mistake: saying “includes revisions” with no number
  • Fix: specify rounds and what counts as a revision.
• Mistake: ignoring overhead
  • Fix: calculate your real rate and include costs.
• Mistake: not charging for extra requests
  • Fix: define change requests and quote separately.
• Mistake: no payment milestones
  • Fix: invoice at the phases you deliver.

When to raise your rates (and when not to)

Raise rates when:

• You’re consistently booked (or you could be with better marketing)
• You’re getting requests for rush work
• Your revisions are predictable and within scope
• You’ve improved your process and can deliver faster

Don’t raise rates when:

• Your deliverables are unclear and you’re dealing with constant scope confusion
• You’re accepting low-quality briefs that cause extra rework

Fix the process first. Then raise prices with confidence.

Conclusion: Pick a model, then operationalize it

Choose the model that matches how the work actually runs:

• Unclear work → hourly or phased deliverables
• Clear scope → fixed
• Work that ships in steps → deliverables

Then operationalize it with:

• A real-rate calculation
• Tiered packages
• Clear proposal terms
• Milestone invoicing and acceptance rules

That’s the repeatable system.

---

Not sure where your freelance business stands? The Freelance Business Check is a quick way to spot weak spots before they turn into late nights or lost income.

Freelance pricing script: quote confidently in 60 seconds

Use this simple script when sending a proposal or quote:

“Here’s the pricing for [deliverable].

• Price: $[amount]
• What’s included: [deliverables list]
• Timeline: [timeline]
• Revisions: [number of rounds]
• What’s excluded: [top 2–3 exclusions]
• Next step: If you’re good with this, we’ll schedule kickoff and invoice the first milestone ($[amount]).”

If the client asks “What if we need extra?”

“That would be handled as a change request. I’ll quote it before we start. If it fits in the included scope, we just proceed.”

Tone matters: calm, factual, and specific.

Related reading: How Much to Charge as a Freelancer: Pricing Tools · Freelance Hourly Rate: Calculate Yours (Step-by-Step)

Freelance pricing FAQs by niche (quick answers)

Marketers (ads, landing pages, SEO)

Q: Should I charge hourly for marketing work? A: If the strategy is still being figured out, hourly can work. For landing pages or content, deliverables or fixed scopes usually sell better.

Q: What about performance pricing? A: If you offer a bonus for results, keep a base fee for the work. Make the bonus measurable and time-bound.

Q: How do I handle “more keywords” or “more pages”? A: Put exclusions in writing. Offer tiered options: basic (limited pages/targets), standard, and growth (expanded scope).

Devs (web apps, integrations)

Q: Is fixed pricing risky for dev projects? A: It can be. Reduce risk by scoping into phases and defining acceptance. Deliverables + milestones are often the sweet spot.

Q: What counts as a bug vs a change request? A: Define it in the proposal: bug = behavior that doesn’t match agreed requirements. Change request = new feature or requirement not in scope.

Q: Should I include support after delivery? A: Yes—briefly. Example: “30 days of post-launch fixes included.” Anything beyond becomes a paid retainer.

Writers (blogs, ebooks, emails)

Q: Do writers charge per word? A: Some do, but deliverables pricing often fits better. Charge by package: topic research + draft + edit + included revision round.

Q: How do I price revisions? A: Include a set number of revision rounds. After that, price additional rounds or new angles as extra deliverables.

Q: What if the client wants new sections late? A: Treat it as a change request. Quote additional sections separately so your original fixed price stays profitable.

Designers (web, brand, decks)

Q: Should I do hourly or fixed for design? A: For defined deliverables (one landing page, one deck set, one logo package), fixed or deliverables works well. For unclear discovery, use hourly for early exploration.

Q: How do I avoid endless “tiny edits”? A: Define what “included revisions” means. Tiny edits inside scope are covered; new pages, extra concepts, or major changes are paid.

Q: What does tiered pricing look like? A: Good/Better/Best often maps to:

• Included concepts
• Included rounds of revisions
• Level of strategy/depth
• Speed (rush option can be a premium)

---## Quick checklist: your next quote is ready Before you send pricing, confirm:

• I used a real-rate calculation
• I chose the model based on scope clarity
• I listed deliverables and exclusions
• I set a revision policy
• I included milestones and acceptance
• I defined change requests

If you want, I can turn this into a one-page pricing template you can copy/paste for your proposals.