How to Estimate a Freelance Project Without Underquoting
A repeatable way to price freelance work so your quote survives contact with the actual project.
The Delivvo team· August 6, 2026 8 min read
To estimate a freelance project without underquoting, break the work into tasks small enough to price, estimate each uncertain task three ways instead of one, add a contingency buffer for what you cannot see yet, and put a number on the risk of a vague brief. Then quote a range, agree the scope in writing, and commit to a fixed figure only after that. Underquoting almost always starts with one habit: turning a fuzzy request into a single confident number too early.
That habit is common, and it is expensive. Below is a method that replaces the guess with a repeatable process, plus the reason accurate estimating matters more than most freelancers admit.
Most projects miss their estimate, so plan for it
Assume your first instinct is optimistic, because the data on real projects says it usually is. In Wellingtone's most recent research, only 36% of organizations said they mostly or always complete projects on time, and just 49% said they mostly or always complete them on budget (Wellingtone). These are teams with project managers, tooling, and formal processes. A solo freelancer working from a two-line brief is not better positioned than they are.
The Project Management Institute measures the same problem from the goal side. In its 2024 Pulse of the Profession report, the average project performance rate, meaning the share of completed projects that met their business goals, was 73.8% (Project Management Institute). Roughly a quarter of projects fell short. The same report names scope creep a key project execution metric and notes that projects with higher performance show lower rates of it and lose less budget when they fail ().
Underquoting is where this bites freelancers hardest, because you carry the overrun yourself. There is no client budget to absorb it. And the reflex to quote low runs deep. In freelancermap's Freelancer Study 2024, 45% of freelancers planned to raise their rates that year, which tells you a large group already suspected they were charging too little (freelancermap). An estimate that runs over quietly reverses any raise you gave yourself.
So the goal is not a lucky guess. It is a number you can defend, tied to work you have actually thought through.
Break the work into tasks you can price
You cannot price a project. You can price a task. The first move is to turn "redesign the website" into a list of pieces small enough that you could put a number on each one without flinching.
For that website, the list might read: discovery call and notes, sitemap, wireframes for five templates, visual design for those templates, a revision round, developer handoff files, and a final walkthrough. Each item now has a shape. You can feel which ones are quick and which ones hide surprises.
Two rules keep this honest.
First, if a task is so big you cannot estimate it in one sitting, it is not a task yet. Split it until each piece feels concrete. "Build the dashboard" is a project. "Build the filters, the table, and the export" is three tasks you can reason about.
Second, write down the tasks that are not design or code. Kickoff, status updates, review cycles, exports, admin, the back-and-forth over fonts. This invisible work is where solo estimates leak. You bill for the deliverable and eat the coordination, then wonder why a $3,000 project paid like $1,800 an hour once you divide by the real hours.
Estimate uncertain tasks three ways, not one
For anything you have done many times, a single number is fine. For anything with unknowns, use a three-point estimate. You give each task three figures: the best case if everything goes smoothly, the most likely case, and the worst case if the ugly version shows up.
The technique comes from PERT, a standard project-scheduling method, and the weighted formula is simple: expected time equals best case plus four times most likely plus worst case, all divided by six. Say a data migration is 6 hours at best, 10 hours most likely, and 20 hours if the export is a mess. The weighted estimate is (6 + 40 + 20) / 6, which is 11 hours. Not the 6 you would have quoted on a good-mood day, and not the 20 that would price you out. Eleven.
Three-point estimating does two things at once. It drags your number toward reality by forcing you to name the worst case out loud, and it exposes which tasks are actually risky. A task where best and worst are 8 and 9 hours is stable. A task where they are 4 and 20 is a warning. That spread is information you want before you quote, not after.
A freelancer outlining a project scope on a laptop at a desk
Add the expected figures across every task and you have a bottom-up estimate built from parts you understand, instead of a round number you pulled from the air.
Add a contingency buffer, and price vague scope as risk
Your task list covers the work you can see. A buffer covers the work you cannot. Every project has some: the file that arrives in the wrong format, the stakeholder who appears in week three, the "quick tweak" that reopens a finished section.
A practical buffer sits between 15% and 25% of the estimate for work you know well, and higher for anything new. This is not padding you hide. It is a line you can explain, because unplanned change is one of the top project management challenges teams report, alongside a lack of visibility into project status (Wellingtone). You are pricing a known risk, the same way an experienced contractor does.
Vague scope deserves its own surcharge. When a brief is thin, you are being asked to quote a shape you cannot see, and the honest response is to price the uncertainty rather than absorb it. Two ways to handle it:
Raise the buffer. A clear brief might carry 15%. A brief that says "make it modern, you know what I mean" carries 30% or more, because the revision risk is real.
Sell a paid discovery phase first. For a fixed $500 to $1,000, you define the scope, produce a spec, and quote the build from something concrete. If the client will not pay for clarity, that itself tells you how the project would have gone.
Scope creep is not bad luck. It is the predictable result of quoting against a fuzzy target. Pricing the fuzz is how you stop paying for it. For the tactics that keep an agreed scope from drifting once work begins, see our guide on how to stop scope creep on freelance projects.
Quote a range first, then a fixed number tied to written scope
Give the client a range before you give them a single figure. A range communicates something a fixed number hides: that the price depends on decisions still being made. "This lands between $4,000 and $6,000 depending on how many templates and revision rounds we settle on" is honest, and it starts a conversation about scope instead of about your rate.
Once the scope is pinned, convert the range into a fixed number and write the scope down beside it. This is the step that protects the estimate. The fixed price only holds for the work described. Anything outside it is a change, quoted separately, not a favor. A short written scope, even a one-page statement of work, turns "that wasn't included" from an argument into a line item. Our freelance statement of work guide walks through what to put in one.
An estimate is only as good as the scope both sides agreed to. If the number lives in a chat thread and the scope lives in your head, you have nothing to point back to when the project grows.
Delivvo gives freelancers a single branded portal for turning an estimate into a proposal and contract the client accepts before work starts, so the number you quoted stays the number on record. See how it works →
For the wider picture on setting rates that hold up, our freelance pricing guide for 2026 covers hourly, fixed, and value-based approaches.
Frequently asked questions
How much contingency should I add to a freelance estimate?
Start at 15% to 25% for work you have done many times, and go higher for anything unfamiliar or defined by a vague brief. The buffer covers predictable unknowns like format problems, late stakeholders, and extra revision rounds. Treat it as a named, defensible part of the price, not padding you feel guilty about.
Should I show the client my estimate breakdown?
Show the structure, not every hour. A client benefits from seeing the phases, the assumptions, and what is in scope versus out, because that is what a change is measured against later. You do not need to expose your internal three-point math or your buffer percentage. The point of sharing is a shared definition of the work, so nobody argues about "that wasn't included."
What if the client only wants one fixed number?
Give one, but only after the scope is written down. Quote a range while the scope is still open, use that range to settle the decisions that move the price, then commit to a fixed figure attached to a short written scope. A fixed number with no agreed scope is not a quote. It is a liability you volunteered for.
The takeaway
Underquoting is a process failure, not a personality flaw. You do not fix it by being braver about big numbers. You fix it by breaking the work into tasks, estimating the uncertain ones three ways, adding a buffer for the unknowns, pricing vague scope as the risk it is, and quoting a range before you lock a fixed price to written scope. Do that, and the number you send stops being a hopeful guess and starts being something you can stand behind, and get paid for.
