Clients tend to prefer a fixed price because it's predictable. They know exactly what they're paying before work starts. Freelancers often prefer hourly because it protects them from scope creep and unpaid extra work. You can get most of the benefit of both by quoting a fixed price that's actually built from an honest internal hourly estimate, rather than a number pulled out of thin air.
The formula, with real numbers
Estimate the hours the work will actually take, multiply by your hourly rate, then adjust for three things most freelancers forget to price in: complexity, revisions, and urgency.
- Complexity: unfamiliar tech, vague requirements, or a client who's never scoped a project before all take longer than the "ideal case" estimate
- Revisions: build in a fixed number of included rounds (two is typical), and price additional rounds separately and explicitly
- Urgency: a compressed timeline means turning down other work to prioritize this one, which deserves a rush premium, not just a faster delivery date
Worked example: a marketing site redesign estimated at 30 hours, at a $60/hour baseline rate, comes to $1,800. If the client's brand guidelines are incomplete (medium complexity, +15%) and they want it in two weeks instead of the usual four (rush, +20%), your quote becomes roughly $1,800 × 1.15 × 1.20 ≈ $2,484. Round it to a clean number like $2,500 and you have a defensible, specific quote, not a guess.
Here's a second example for a bigger, riskier project: a 6-week app feature build, estimated at 120 hours, at a $75/hour rate, comes to $9,000 as the raw baseline. This is a longer project with more that can go wrong, so the adjustments matter more, not less. The client's backend isn't fully documented, so you're estimating against an API you don't fully understand yet (high complexity, +25%). There's no urgency premium since the timeline is reasonable, but you add a separate margin-for-error buffer of 10% specifically because longer projects have more opportunities for scope to drift in small, hard-to-notice ways. That's $9,000 × 1.25 × 1.10 ≈ $12,375. On a project this size, it's worth presenting that number broken into the same milestone structure you'd use for billing, so the client sees where the money goes instead of just one large total that invites negotiation on the whole figure.
Always calculate a range internally, even if the client only sees one number
Alongside your recommended price, work out a "minimum acceptable" number, the lowest you'd take this project for and still feel good about it. If a client negotiates, you know exactly how far you can go without working below what the project is actually worth to you. Without this number, negotiation pressure tends to win, and you find out you've agreed to something uncomfortable only after the contract is signed.
When hourly genuinely is the better choice
Fixed price works best when the deliverable is well-defined: a five-page website, a logo package, a single feature. It works poorly when the project is exploratory: research-heavy work, a vague "help us figure out our tech stack" engagement, or anything where the client themselves doesn't fully know what they want yet. In those cases, hourly billing (often with a not-to-exceed cap for the client's comfort) is the more honest structure, because neither side can accurately estimate total hours upfront. Saying "I'd actually recommend hourly for this because the scope isn't fully defined yet" tends to build more trust than forcing a fixed quote onto a fuzzy project and eating the overage yourself later.
What to do when a client pushes for "just tell me your hourly rate"
Some clients specifically want hourly because they've been burned by vague fixed quotes before, or they want visibility into where time goes. That's a reasonable ask. You can offer hourly with a not-to-exceed estimate ("I bill at $X/hour, and based on the scope we discussed, I don't expect this to exceed $Y"), which gives them the predictability of a fixed price and you the protection of hourly billing if the scope shifts.
Retainers: a third option that isn't hourly or fixed
Hourly and fixed price both assume a project with a beginning and an end. Retainers are a different shape entirely: the client pays a set amount every month for ongoing access to your time or a defined bucket of deliverables, regardless of exactly how the hours land week to week. They make sense once a client relationship moves from "one project" to "ongoing need," like a business that wants a blog post and two social graphics every week, or a startup that wants a developer on call for bug fixes and small features indefinitely.
Price a retainer by estimating the average monthly hours the work will take, multiplying by your hourly rate, then adding a smaller premium than you would for rush work, typically 10-15%, to compensate for the flexibility and priority access the client is buying. If a content retainer realistically takes 15 hours a month at a $65/hour rate, that's $975 as a baseline, and a $1,100-1,125/month retainer is reasonable once you price in that the client expects you to drop other things when something urgent comes up. The real risk with retainers isn't underpricing the hours, it's scope bleed: clients gradually expanding what "included" means until the retainer covers far more than it was priced for. Defining exactly what's in scope, and what counts as a billable add-on, before the first month starts prevents most of that drift.
Value-based pricing for high-stakes deliverables
Time-based pricing, whether hourly, fixed, or retainer, assumes the value of your work is roughly proportional to the hours it took. That assumption breaks down completely for certain projects. A landing page that takes you 25 hours to build is priced very differently depending on whether it's a portfolio page for a freelance illustrator or the primary conversion page for a product launch the client expects to generate $50,000 in new revenue in its first quarter. The hours are similar. The value created is not.
For projects like that, it's worth pricing partly or fully based on the value the deliverable is expected to create rather than the time it took to build. If a client tells you, even informally, that a project is expected to drive a specific revenue number, you can anchor your price as a small percentage of that expected outcome rather than your usual hourly math. A $50,000 expected revenue lift easily justifies a $5,000-8,000 project fee, even if your hourly estimate would have produced something closer to $2,500. The client is still getting a great deal relative to the value created, and you're being paid for impact instead of just effort.
Value-based pricing works best when you can point to a concrete number the client themselves has stated or implied, not a number you've invented to justify charging more. Without that anchor, it just looks like an arbitrary markup, and clients will push back accordingly.
What to do when you've underbid a fixed-price project
Sometimes you get the scope wrong. The brand guidelines you were promised never materialized, the client keeps adding "just one small thing" that adds up to a second project, or you simply misjudged how long the work would take. The instinct to quietly eat the overage and never bring it up is understandable, but it trains the client (and yourself) to expect unlimited scope for a fixed price, and it makes the same thing more likely to happen on the next project.
The better move is to flag it as soon as you notice the gap, not at final delivery. Be specific and factual rather than apologetic: "The original quote was based on three rounds of feedback covering the homepage and two subpages. We're now on round six and have added two new subpages that weren't in the original scope. I can finish the current additional work for $X, and I'd suggest we revisit the quote structure for anything beyond that." This works because it separates the work you already agreed to (which you should finish as quoted, even at a loss, to protect the relationship and your reputation) from new work that was never priced in. Clients who are reasonable will usually agree immediately, because most scope creep happens gradually and they often haven't tallied up how much has actually been added.
Split payment into milestones
A 50/50 split, half on project start, half on delivery, is the simplest version and works well for projects under a few weeks. For longer projects, add a third milestone at the midpoint: 30% on start, 40% at a defined checkpoint (like first draft delivered), and 30% on final delivery. This protects you if a project stalls partway through, gives the client visibility into progress, and means you're never more than one milestone's worth of unpaid work away from being made whole if something goes wrong.
The underlying goal either way is the same: replace gut-feel pricing with a number you can actually explain, line by line, if a client asks "how did you arrive at this?" That clarity is itself a selling point. Clients trust freelancers who can show their reasoning far more than ones who can only say "that's just what I charge."