How to estimate a software project as a freelancer

To estimate a software project as a freelancer: break the work into pieces small enough that you have built each one before, give every piece a range in days, add the work that is not features (setup, testing, launch, communication), widen the total for anything unknown, and quote from the high end of the range. Then price the outcome, not the hours, and write down what the number assumes.

Most freelancers estimate by feel: read the brief, picture building it, say a number. That number is almost always the best case, because the picture in your head is the version where nothing goes wrong. The method below is slower by about an hour and wrong by much less.

Why freelance estimates go wrong

The common failures are predictable, which is the good news, because predictable failures can be designed out.

• The forgotten work. Deployment, environments, emails, error states, the admin screen nobody mentioned, app store submission. None of it is in the brief, all of it is in the project.
• Single numbers. "Three days" hides whether you mean three days if it goes well or three days if it goes badly. You almost always mean the first.
• Someone else's code. Extending an existing codebase is slower than building fresh, and how much slower is unknown until you have read it.
• The client's side. Waiting for feedback, content, access and decisions. It is not your work, but it is your calendar.

Step 1: break it into pieces you have built before

List every piece of the project at a size you can picture finishing. A good test: if a line would take more than about three days, it is still several lines.

"User accounts" is too big. "Sign-up with email", "password reset", "Google sign-in" and "account settings page" are the right size, because you have built each of those and you know roughly what they cost.

Anything you have never built before gets its own line, marked. That line is where the risk lives.

Step 2: give every piece a range

For each line, write two numbers in days: the realistic low and the realistic high. Not the fantasy and the disaster; the version where it goes normally and the version where the usual things go wrong.

Here is the worked example the project cost estimator loads with: a web app with accounts, payments and an admin area, finished designs provided, and a written spec. The ranges are its starting points in developer-days, not anyone's market data.

That is roughly 6 to 13 weeks of one person's work. The gap between the two numbers is not sloppiness. It is an honest description of what you do not know yet.

Step 3: add the work that is not features

The line people leave out most is the one at the bottom of that table: setup, testing and launch. Repositories, environments, deployment, error tracking, the bug fixes after the client first uses it properly, and the launch itself.

Then there is communication. Calls, emails, demos, written updates, answering the same question twice. On a small project with an involved client, it can be a surprising share of the total. Either add it as its own line or make sure your ranges already absorb it, but decide which, on purpose.

Step 4: widen it for the unknowns

Some situations make every line slower. Apply them to the total rather than trying to spread them across lines. The estimator uses these multipliers, and they are a reasonable starting point:

• Extending an existing codebase: x1.25. Reading someone else's code is work, and what is in there is unknown until it is read.
• Just an idea, no spec: x1.15. Someone has to turn the idea into a spec before anyone can build it, and that someone is usually you.
• Must handle real traffic from day one: x1.15.
• Regulated data (health, finance, children's): x1.25.

For a large unknown, such as an integration with a system you have never seen, do not guess. Propose a short paid discovery first: a few days to read the code or test the API, with its own price, after which you quote the rest properly.

Step 5: turn days into a quote

Now you have a range in days. To turn it into money you need a day rate you can defend. If you have not worked yours out from what you actually need, the rate calculator does it and shows the working, and how much to charge as a freelance developer explains the method.

Then quote from the high end of the range, as a fixed price for a defined outcome. If the work goes well, you finish early and the margin is yours. If it goes badly, you are covered. Quoting from the low end means every normal problem comes out of your pocket.

Fixed price or hourly goes into when each makes sense. For a well-defined project, fixed is usually better for both sides.

Write down what the number assumes

An estimate without assumptions is a promise. An estimate with them is a plan. Put them in the quote, in plain words:

This price assumes finished designs for every screen before development starts, payments through Stripe in one currency, feedback on each milestone within three working days, and hosting on your accounts. Changes to any of these may change the price, and I will tell you before doing extra work.

That paragraph is also your best defence against scope creep, because when the scope changes you can point at what was agreed instead of arguing about what was meant.

Check your estimates against what actually happened

After every project, put your estimate next to the real number of days, line by line. It takes ten minutes and it is the only way your estimates get better. A made-up example of what that looks like:

Patterns appear after a few projects. In the example above the features land inside the range, while payments and launch run over, which is a typical shape: the work you control is predictable, and the work that touches someone else's system is not. Once you know your own bias, correct for it, and every quote gets a little better than the last one.