How to Estimate How Long a Freelance Project Will Take

A client asks how long the project will take. You do the arithmetic in your head — three days of writing, a day of revisions, call it a week — and you say “about a week.” Three weeks later you are apologising.

Here is the thing that took me an embarrassingly long time to see: in that exchange you were probably right about the work and wrong about the answer, because “how long will it take” is two questions wearing one coat. There is effort — how many hours of your hands does this need — and there is elapsed time — what date does it land on the client’s desk. They are governed by completely different forces. Effort is a measurement problem, and measurement problems get solved by keeping records. Elapsed time is a dependency problem, and no amount of record-keeping fixes it.

Almost every missed freelance deadline I have seen described online is an elapsed miss, not an effort miss. The freelancer did roughly the hours they said they would. The date moved because a logo file arrived on day nine, or because feedback came back from three people who disagreed with each other, or because the freelancer had two other clients that month and could only give this one eleven hours a week.

This is a method for answering both questions, in that order, and for building the one record that makes every future estimate cheaper to produce. It pairs with tracking billable hours accurately — you cannot estimate what you have never measured — and with setting a rate you can defend, because an estimate is what turns a rate into a price.

The question has two answers and you only ever give one

Say a project genuinely needs 40 hours of your work. Notice how naturally the next step goes wrong: 40 hours divided by 8 is 5 days, five days is a week, “about a week.”

That calculation assumes you will spend eight hours a day, every day, on this one project, starting tomorrow, with no waiting. You have never had a week like that. Nobody has. If you run three clients, the honest number of focused hours you can give any single project in a week is somewhere between ten and twenty, and that is before the client goes quiet for four days in the middle.

So the two numbers are 40 hours and — as you will see below — something closer to four weeks. Both are true. Only one of them is what the client asked for, and it is not the one you gave them.

Step 1: break the work into named phases before you put a number on anything

A single number for a whole project is a guess dressed up as an estimate. Break it into phases you can name, and each phase becomes something you have either done before or have not — which turns out to be the only distinction that matters.

For a website copy project that might be: discovery call and brief, audit of existing pages, message framework, first draft, revision round one, revision round two, handoff and upload. Seven phases. You have probably done six of them thirty times, and one of them — say, the message framework — twice.

Estimate each phase separately, out loud, and write the number down before you total them. Two things happen. First, the phases you have never done stand out, and those are the ones that blow up. Second, you now have a structure you can quote from and, later, a structure you can compare against reality. This is also the shape you want in the proposal itself, because a client who can see phases can see what they are buying.

Step 2: add the hours that never make it into the estimate

Almost every freelancer estimates the visible middle of the project — the drafting, the designing, the building — and silently omits the rest. The omitted parts are not small.

Kickoff and briefing calls. Reading the client’s existing material. The email thread where you clarify what they meant. Consolidating feedback from three people. Preparing files for handoff in the format their developer wants. The walkthrough call. Invoicing and chasing the invoice.

On a 40-hour project, that surrounding layer is routinely eight to twelve hours. It is real work, it happens because of this project, and it is invisible in your estimate because it does not feel like the job. Add it explicitly as its own phase and stop pretending it is free. If you have never measured it, that is exactly what time tracking is for: not to bill in six-minute increments, but so that next quarter you know your own overhead per project instead of guessing at it.

Step 3: turn hours into a date using your real weekly capacity

Now the conversion nobody does. Take the total hours and divide by the hours you can genuinely give this project per week — not your total working week, the slice this client gets. Then add client turnaround for each review round.

Here is that arithmetic for a 40-hour project, assuming two review rounds and a realistic three business days for the client to come back each time. Treat this as a worked model with stated assumptions, not a measurement:

Hours you can give this project per week	Working weeks for 40 hours	Client turnaround, 2 rounds	Elapsed time to quote
5 (a side project around a full book)	8.0	+1.2 weeks	~9 weeks
10	4.0	+1.2 weeks	~5 weeks
15 (typical for one of three active clients)	2.7	+1.2 weeks	~4 weeks
20	2.0	+1.2 weeks	~3 weeks
30	1.3	+1.2 weeks	~2.5 weeks
40 (this is your only client, all week)	1.0	+1.2 weeks	~2 weeks

Read the bottom row twice. Even in the fantasy scenario where you drop everything and work on nothing else, “a week of work” is a two-week delivery, because the client still has to look at it. The gap between what you said and what happened was never about your speed.

The realistic row — fifteen hours a week — gives about four weeks for a job you would have described as “about a week.” That is not padding. That is the same 40 hours, correctly converted.

Step 4: write down what you are waiting for, and from whom

Everything that moves a delivery date in the wrong direction, other than your own capacity, is something you are waiting for. So list them, in the proposal, with names and dates attached. I call it a dependency register, which sounds grander than it is: five rows in a table.

What you are waiting for	Who owes it	Needed by	Typical turnaround	What slips if it is late
Brand assets, fonts, logo files	Client’s marketing lead	Day 1	2–5 business days	Everything. Work cannot start.
CMS or repo access	Client’s developer	Day 3	1–10 business days	Build phase only
Round 1 feedback, consolidated	One named approver	Day 12	3 business days	Delivery date, day for day
Final pricing figures	Client’s founder	Day 15	Unknown	Handoff
Legal or compliance sign-off	Client’s legal	Day 20	5–15 business days	Launch, not the work

Two details do the heavy lifting here. The first is one named approver. Feedback from a committee is not feedback; it is a negotiation you are hosting for free, and it is the single most reliable way for a three-day turnaround to become nine. Name one person in the document.

The second is the last column. When something is late, you do not have to argue about whose fault the delay is — the register already said what it would cost, and you both signed it. That is the same principle that makes scope creep survivable: the disagreement is never really about goodwill, it is about two people arguing from memory. Write it down and there is nothing to argue about. The register belongs alongside the payment terms in your contract.

What “just add a buffer” actually buys you

The standard advice is to pad your estimate by twenty or thirty percent. It is not wrong, exactly. It is aimed at the wrong target.

Buffer on a 40-hour estimate	Extra hours bought	What it absorbs	Days of client delay it absorbs
+10%	4	One small unplanned fix	Zero
+25%	10	One phase you mis-sized	Zero
+50%	20	A real scope addition — which you should be invoicing, not absorbing	Zero
+100%	40	A project you did not understand when you quoted it	Zero
+0%, with a dated dependency register	0	Nothing	All of them

Every buffer is denominated in hours. Every calendar overrun is denominated in days you did not spend working. A hundred percent buffer absorbs zero days of a client sitting on your draft, because the problem was never that you needed more hours. Buffer your hours if your hours are unreliable — and the log in the next section will tell you whether they are — but fix your dates with a register, not with padding.

There is also a quiet cost to habitual padding: it makes you more expensive on fixed-price work without making you more accurate, and clients who compare quotes will notice before you do.

The two-column log that makes every future estimate cheaper

Here is the whole system, and it is genuinely two columns: what you estimated, and what it actually took. Add project type and you can compute a ratio. After eight projects you stop guessing and start reading.

This is what a year of that log tends to look like once you have enough rows to see the shape. Again — a worked model built from the pattern, not a claim about a specific person’s books:

Project	Estimated hours	Actual hours	Ratio
Four blog posts, existing template	16	17	1.06
Retainer month, same scope as last month	20	22	1.10
Landing page copy (done this six times)	12	14	1.17
Email sequence, five mails	10	13	1.30
Logo plus basic brand kit	25	33	1.32
Brand messaging workshop plus document (first time)	20	38	1.90
Website copy migration, 40 pages (first time)	30	71	2.37
“Quick” homepage refresh, scoped in one sentence	8	21	2.63

The average ratio across those eight is about 1.48, and that number is useless. Look at the spread instead: 1.06 to 2.63. It does not scatter randomly — it clusters, and it clusters on one variable.

Work whose shape you have shipped before lands between 1.06 and 1.32. Work whose shape is new to you lands between 1.90 and 2.63. Not harder work. Not bigger work. Unfamiliar work. That means the useful question to ask yourself before quoting is not “how long will this take,” which you cannot answer, but “have I shipped this exact shape before,” which you can answer instantly and honestly.

Which gives you two multipliers instead of one generic buffer. Roughly 1.2 for familiar shapes, roughly 2.0 for new ones. Applied to phases, not to the whole project — because most projects are six familiar phases and one new one, and only that one needs doubling.

The word “quick” is a risk marker, not a scope marker

Notice which row is worst. Not the 40-page migration — the eight-hour “quick homepage refresh,” which came in at 2.63x. This is consistent enough that I would treat it as a rule: when a brief arrives containing the word quick, or simple, or just, the client has compressed an unspecified amount of work into an adjective. Nobody is being dishonest. They genuinely do not know, and the adjective is standing in for the specification that does not exist yet.

The fix is not to inflate the number. It is to refuse to quote until the sentence is longer. “Happy to do that — before I put a number on it, can you tell me which sections change and who signs off?” costs you one email and removes most of the 2.63.

Where the estimate field lives in the tools, and what it costs

Most freelancers do not know this: the time tracker they already use almost certainly has a field for estimated hours that sits next to the actual hours and does the comparison for them. Almost nobody fills it in, partly because in two of the three most popular trackers it is behind the paywall.

I checked the official pricing pages and help centres today. Here is where the estimate-versus-actual field actually lives:

Tool	Cheapest plan with an estimate field	Price, billed annually	Cost per year	The catch
Harvest	Free	$0	$0	Free is 1 seat and 2 active projects
Clockify	Basic (“Time estimate”)	$3.99 per user/month	$47.88	Free has unlimited projects but no estimate field
Clockify	Pro (budgets, alerts, forecasting)	$7.99 per user/month	$95.88	Estimates are split across two paid tiers
Toggl Track	Starter (“project time estimates and alerts”)	$9 per licence/month	$108	Free plan has no estimates at all
Toggl Track	Premium (forecasts, fixed-fee projects)	$14 per licence/month	$168 year one, $216 after	$14 is a first-year rate; it renews at $18
A spreadsheet	—	$0	$0	You have to remember to fill it in

Three things jump out of that table.

Harvest gives the estimate away and then caps the thing you need it for. Project estimates are listed as included on Harvest’s free plan, which is genuinely unusual — but free is one seat and two active projects, and the whole value of an estimate log is having eight rows in it, not two. Harvest’s paid Teams plan starts at $9 per seat per month billed annually ($108 per seat per year, or $11 monthly), and on top of the seat rate it charges usage-based fees once you pass the included allowances for projects, clients, tasks and invoices. So the base rate is not the bill.

Clockify sells estimates twice. A plain time estimate on a project appears in Basic at $3.99 per user per month annually — $47.88 a year, the cheapest way to buy this capability outright. But budgets, alerts and forecasting are a Pro feature at $7.99 ($95.88 a year). Clockify’s free plan, which is otherwise the most generous in the category with unlimited projects and up to five users, has no estimate field. That is worth knowing if you read our Clockify review and assumed free covered everything.

Toggl’s headline annual price is a first-year price. This is on their own pricing page, in a footnote under the Premium card: $14 per licence per month “applies to your first year of Premium annual, then renews at $18.” That is a 28.6% increase in year two, on a plan you chose partly on price. Starter — where “project time estimates and alerts” actually live — is $9 annually, so $108 a year, with no renewal footnote. If you like Toggl’s tracking, and plenty of people do, Starter is the tier that buys you estimating.

My recommendation, and it will save most readers a hundred dollars: start in a spreadsheet. Two columns and a date. The log is a habit before it is a feature, and if the habit does not survive a spreadsheet it will not survive a subscription either. If it does survive three months, Clockify Basic at $47.88 a year is the cheapest place to move it, and you get the rest of Clockify’s tracking with it. Toggl Starter at $108 is worth it if the alerts matter to you — being emailed when you cross your estimate is a genuinely different experience from noticing afterwards. Harvest’s free plan is right only if you truly run two projects at a time. Our wider time tracking comparison covers what else separates them. [AFFILIATE: toggl] [AFFILIATE: clockify] [AFFILIATE: harvest]

[PLACEHOLDER: captura]

Your project management tool matters much less here than people assume. A board tracks state, not history, which is why the Notion versus Trello question comes down to whether you need a record or a status — and why, if you want estimate history, the tracker is the place to keep it, not the board. Project management tools are a different job with a different shortlist.

How to say it to the client without sounding slow

All of this is worthless if the delivery is “well, it depends.” It should not be. Here is the shape that works, in three sentences.

First the effort, because it justifies the price: “This is about 45 hours of work across five phases.” Then the date, because it is what they asked for: “Working on it alongside my other commitments, that lands on the 30th.” Then the conditions, because that is what protects the date: “That assumes brand files by Friday and consolidated feedback within three working days of each draft — if either slips, the date moves by the same amount.”

Nobody hears that as slow. They hear it as somebody who has done this before, which is the actual impression you are competing on. Vagueness reads as inexperience; a dated dependency is the opposite.

And when something does slip, you send one line on the day it slips — not the week the deadline arrives. “Legal sign-off has not come through, so the 30th becomes the 4th.” No apology needed, because the register already covered it.

[PLACEHOLDER: nota de experiencia propia]

Who should skip most of this

If you do one kind of project, for one kind of client, at one size — the same website build, the same monthly retainer, the same photo shoot — you do not need a phased estimate or a dependency register. You need the last three invoices. Your ratio is already 1.1 and stable, and formalising it is administration for its own sake. Quote from history and move on.

You should also skip this if your problem is not estimating at all. If projects run long because scope keeps growing after the quote, that is a scope problem and a better estimate will not touch it. If they run long because you are taking on more than you can deliver, that is a pipeline and pricing problem — raising your rate fixes more of it than any spreadsheet will.

And if you genuinely have no idea where your hours go, do not start here. Start by measuring for one month, then come back. Everything above depends on having numbers to compare against, and the rest of the stack is covered in our guide to the software that runs a one-person business and in the time tracking and project management section.

Frequently asked questions

How much should I pad a freelance estimate?

Pad by shape, not by habit. Work you have shipped before typically comes in around 1.1 to 1.3 times your estimate; work whose shape is new to you comes in closer to 1.9 to 2.6 times. Apply the multiplier to the unfamiliar phases only, rather than inflating the whole project by a flat percentage — most projects are mostly familiar.

Should I give the client hours or a delivery date?

Both, in that order, plus the conditions attached to the date. The hours justify the price and the date answers the question they actually asked. Give only hours and they will do the eight-hours-a-day arithmetic themselves and arrive at a date you never agreed to.

Why do my projects always take longer than I estimated?

Usually one of three reasons, and only one of them is about your speed. You estimated the visible middle and omitted briefing, feedback consolidation and handoff. You converted hours to days assuming a full working week on one project. Or you were waiting on the client and never wrote down what you were waiting for. Check them in that order.

What is the cheapest way to track estimated versus actual hours?

A spreadsheet with two columns, which costs nothing and tests whether you will keep the habit. If it sticks, Clockify’s Basic plan includes a time estimate at $3.99 per user per month billed annually ($47.88 a year); Toggl Track puts project estimates and alerts in Starter at $9 per licence per month ($108 a year); Harvest includes project estimates on its free plan but limits you to one seat and two active projects.

How do I estimate a project I have never done before?

Break it into phases and be honest about which ones are new. Estimate the familiar phases from your log, then either double the unfamiliar ones or, better, do a paid discovery phase first — a short, separately quoted piece of work whose deliverable is the estimate for the rest. Clients rarely object, because they would also like a real number.

What should I do when the client causes the delay?

Say so on the day it happens, in one neutral sentence, and restate the new date. If the dependency register was in the proposal, this is a status update rather than a confrontation. If it was not, the conversation is harder — which is the argument for putting it in next time.

The short version

You owe the client two numbers, and until now you have been giving one. Estimate the effort in named phases, including the invisible surrounding hours. Convert that into a date using the hours you can genuinely give this project in a week, not a fantasy full-time week. Write down what you are waiting for and from whom. Then log estimate against actual, every time, until you know your own two multipliers.

The first project you do this way will feel slower to quote. By the eighth, it will be faster than guessing — and you will stop apologising.