How to Estimate Project Time as a Freelancer

"That should take about two days." Most freelancers have said it, and most have watched two days turn into four. Underestimating is so common that psychologists have a name for it: the planning fallacy, described by Daniel Kahneman and Amos Tversky in 1979. People predict how long their own tasks will take based on the best case, even when they know similar tasks took longer before.

You cannot switch that bias off. But you can use a method that corrects for it. This guide walks through four steps and a worked example. To run them on your own project, use the project estimate calculator.

Why estimates go wrong

• Best-case thinking. You imagine the task going smoothly, without interruptions or surprises.
• Forgotten work. Calls, emails, file exports and revisions are part of every project and almost never part of the estimate.
• Big chunks. "Design the website" is too large to estimate. Large tasks hide their size.
• Waiting time. Feedback that takes a week does not cost you hours, but it moves the deadline.
• No feedback loop. If you never compare your estimates with what happened, you make the same mistake on every project.

Step 1: Break the work down

Split the project into tasks no larger than one working day. If a task feels like "a few days", break it again. Smaller tasks are easier to picture, and picturing them is what makes estimates accurate.

A useful test: could you describe the result of the task in one sentence? "Homepage design, desktop and mobile, ready for feedback" works. "Website" does not.

Step 2: Estimate in ranges

A single number pretends to be certain. A range admits that it is not. For each task, write down three numbers:

• Best case: everything goes smoothly.
• Likely: a normal amount of friction.
• Worst case: the realistic bad case, not a disaster.

Then combine them with the three-point (PERT) formula, which weighs the likely case most but still lets the risk pull the number up:

Estimate = (best + 4 × likely + worst) ÷ 6

A task with 2 hours best case, 4 likely and 12 worst case comes out at (2 + 16 + 12) ÷ 6 = 5 hours, more than the likely case, because the risk is lopsided. That is the point: real tasks rarely go much better than expected, but they often go much worse.

Step 3: Add the work nobody lists

Every project contains work that is not in the task list:

• Calls and meetings, including preparation and the recap afterwards
• Email and chat with the client
• Feedback rounds and small corrections
• Project management: planning, updating the client, chasing inputs
• Exporting, handing over files, writing documentation

For most freelance projects this adds 15–25% on top of the task estimates. Projects with many stakeholders or many meetings sit at the top of that range.

Step 4: Apply your personal factor

This is the step that makes estimates get better over time. If you track your time, compare your estimates with what you actually spent on your last few projects:

Personal factor = actual hours ÷ estimated hours

If your last projects took 52, 46 and 61 hours against estimates of 40 hours each, your factor is about 1.3. Multiply new estimates by it until your numbers improve. Without time data you are guessing; with a few projects of data you are calibrating.

A worked example

A five-page website for a fictional café, estimated task by task (all numbers in hours):

Now the two corrections:

The gut feeling, adding up the "likely" column, says 39 hours. The method says 61. If the actual project lands anywhere near 61, that is the difference between a profitable project and one that quietly paid half your rate.

From estimate to quote

Multiply your estimate by your hourly rate: 61 hours at €75 is €4,575, so a quote of €4,600. If you quote a fixed price, the ranges and your personal factor already cover most of the risk. Keep any extra contingency small and say clearly what is included, so additional wishes become change requests, not scope creep.

When a client pushes back on the price, reduce the scope, not the estimate. Cutting hours from an honest estimate only moves the problem to the end of the project.

From estimate to calendar

An estimate in hours is not yet a plan. Put the work into your calendar in blocks, and plan only about two thirds of your available time, because other clients, calls and surprises will claim the rest. Our guide to weekly planning with several clients shows how.

Plan the waiting time too. If the client needs a week for feedback, the deadline moves by a week, even though your hours don't change.

Learn from every project

At the end of each project, spend ten minutes comparing estimate and actual, task by task:

• Which tasks ran over, and why?
• Which hidden work did you forget?
• Did your personal factor improve?

Write the answers down. After five projects you will have a short list of your typical blind spots, and that list is worth more than any formula.

Checklist

• Tasks broken down to one day or less
• Three numbers per task: best, likely, worst
• PERT estimate per task
• 15–25% added for calls, email and revisions
• Personal factor applied from your own time data
• Waiting time planned into the timeline
• Estimate and actual compared after the project

Plan with your real numbers

Winnie tracks your time per client, so your personal factor comes from data instead of memory. Tasks wait next to a week view, and you drag them into free slots, resize them to the estimated duration and see them in Google Calendar too. See the calendar.