How to Price a Freelance Project

Pricing is the part of freelancing nobody teaches you, and the part most freelancers get wrong in the same two ways: underpricing out of fear of losing the job, or pricing by gut feel and hoping it works out. Neither is a pricing method: they're guesses with different amounts of anxiety attached. This guide covers the three real pricing models, how to actually calculate a number from them, and the mistakes that quietly cost freelancers money on otherwise-successful projects.

The three pricing models, and when each one works

Hourly

You bill for time spent, at an agreed rate. It's the easiest model to justify to a client, the logic is transparent, and the easiest to start with if you don't yet have a strong sense of how long your own work takes.

The problem is structural, not situational: hourly pricing penalizes you for getting better at your job. The faster and more efficient you become, the less you earn per project, because your value is measured in time rather than outcome. It also puts the estimation risk on the client's side of the table: they're agreeing to an open-ended number, which makes some clients (reasonably) nervous, and makes budget approval harder on their end.

Hourly makes the most sense for work that's genuinely unpredictable in scope: ongoing maintenance, open-ended consulting retainers, or a brand-new client relationship where you don't yet have enough information to quote a flat number responsibly.

Flat fee

You quote one number for the defined scope. The client knows exactly what they're paying, and you keep the upside if you finish faster than expected: the tradeoff is that you also absorb the cost if the work takes longer than planned.

This only works well when the scope is specific. A flat fee against a vague scope is a bet you're likely to lose, because "redesign the website" can expand in ways a client won't see as expansion: they'll see it as what they always meant. The fix isn't to avoid flat-fee pricing; it's to write a scope specific enough that both sides can point to it later (see the section on scope-based buffers below).

Flat fee is the most common model for project-based freelance work, logo design, a website build, a defined marketing campaign, precisely because those projects usually have a describable endpoint.

Value-based

You price based on what the outcome is worth to the client, not the hours it takes you. A landing page redesign tied to a measurable increase in conversion rate might be priced against the revenue impact, not the design hours. Done well, this is the highest-earning model, because your price scales with the client's actual stakes rather than your time.

It's also the hardest to defend, and only works when you can make a credible case that the outcome is attributable to your work specifically, not a coincidence, not market conditions, not something the client would have gotten anyway. For most project types, "the client agreed the outcome mattered this much to them" has to come from an actual conversation about stakes, not an assumption on your part.

How to actually calculate a flat fee

Most freelancers who use flat-fee pricing still start from an hourly baseline, even if the client never sees that number. The process:

1. Estimate the hours honestly, including the work that isn't the visible deliverable: revisions, client communication, file handoff, administrative time around the project. A project that takes 20 hours of "doing the work" often takes 28-30 hours all-in.
2. Multiply by your target hourly rate to get a baseline number.
3. Add a scope buffer (see below) rather than quoting the bare-minimum estimate.
4. Round to a number that reads as considered, not a number that looks like you backed into it from an hourly calculation: $4,700 reads as a real quote; $4,683.50 reads like a spreadsheet nobody double-checked.

The hourly number is scaffolding, not the final price. Once you have it, the question becomes whether that number actually reflects the value of the outcome, and if the project has real strategic weight for the client, that's the moment to consider pricing above the hourly-derived baseline rather than treating it as the ceiling.

Building in a buffer for scope and revisions

Every flat-fee quote should include a buffer, for two separate reasons: your own estimate is probably optimistic, and scope has a tendency to expand even when nobody's acting in bad faith. A client asking for "one small change" five times is still five changes.

The practical way to handle this: price in a specific number of revision rounds as part of the quoted fee, and state clearly what happens beyond that (an hourly rate for additional rounds is the most common approach). This does two things, it protects your margin, and it gives the client a concrete signal about what "included" actually means, which heads off the awkward conversation where they assumed unlimited revisions were part of the deal.

A reasonable buffer for a well-scoped project is 10-15% added to your honest hourly-derived estimate. For a project where the scope is less certain, a first engagement with a new client, or work in a domain you're less experienced in, 20-25% is more realistic, and a value-based conversation about what happens if revisions run genuinely long is worth having upfront rather than after the third round.

Deposits: why they matter and what's typical

A deposit isn't just about cash flow, though that matters too, it's a commitment signal. A client who pays a deposit has demonstrated they're serious, which filters out the "maybe later" inquiries that cost you time without ever converting. It also means you're not financing 100% of the work before seeing a cent.

50% due at signing, with the remainder due on delivery or on a set date, is the most common split for project-based freelance work. For a larger project, splitting into more stages (a portion at signing, a portion at a defined milestone, the remainder on completion) can work better for both sides, though note that most proposal tools, VEYQO included, are built around a single deposit-plus-remaining-balance structure rather than open-ended multi-way milestones, so if you want several distinct payment points, the simplest approach is often a deposit at signing and a separate invoice at each later milestone.

Smaller or very short projects can reasonably skip a deposit if the relationship is established and the amount is modest: the administrative overhead of invoicing twice may not be worth it under a certain project size.

How tax factors into what you quote

Whether you quote a price before or after tax depends entirely on your jurisdiction's rules and how you handle it elsewhere in your business: this isn't something a guide can tell you definitively, since the right answer varies by where you and your client are located. What matters practically is being explicit: state clearly whether your quoted number includes tax or not, and if you're applying a tax rate, show how it's calculated rather than folding it silently into a round total. A client should never have to ask "wait, is that including tax?" after they've already agreed to a number.

If you want to see exactly how a discount and tax rate affect a final number and deposit split before you send a quote, VEYQO's free pricing calculator runs the actual math, subtotal, discount applied first, tax calculated on the discounted amount, then the deposit split, so you can check a number before it goes in front of a client.

Common pricing mistakes

Underpricing to win the job. A price that's too low to win doesn't just cost you margin on this project, it anchors the client's expectation for every future project and every referral they make on your behalf. If you're regularly winning every quote you send, that's a signal your prices are probably too low, not a sign of strong sales skills.

Not accounting for non-billable time. Proposal writing, client calls that aren't part of the delivered work, revisions beyond what's included, administrative overhead, none of that is "free" just because it isn't the visible deliverable. If your hourly-derived estimate only counts the hours you'll spend with a design tool or code editor open, it's missing real cost.

Quoting a number that doesn't survive a follow-up question. If a client asks "why $4,700 and not $4,000," you should have an answer rooted in the scope and the work, not "that's what felt right." A price built from an actual estimate, even one you don't show the client, holds up under that question. A number pulled from thin air doesn't, and it shows.

Discounting the same scope instead of adjusting it. When a client pushes back on price, cutting the number without changing the deliverable teaches them your first quote had padding in it, which makes the next negotiation, on this project or the next one, harder. Adjusting scope to fit a lower number, instead, keeps your rate intact and makes the tradeoff explicit rather than implicit.

A price you can explain, tied to a scope you've actually estimated, with a deposit that protects your time, that's the whole method. Everything else is detail.