How I Estimate Web Projects as a Team Lead

TL;DR: I estimate web projects in five steps: break the work into tasks of two to three days or less, give each task an optimistic, likely and pessimistic estimate, combine them with the PERT formula, add overhead for reviews, QA, meetings and deployment, then add a risk buffer and quote the result as a range. Estimates are forecasts, so I re-estimate at checkpoints instead of defending the first number.

Estimation is one of the first things clients ask a team lead for, and one of the easiest things to get wrong. Here is the process my team uses for client projects, with a worked example you can copy.

Key takeaways

• Never estimate anything bigger than two or three days as a single number. Break it down.
• Use three-point estimates. The pessimistic number is where the honesty lives.
• Coding is only part of the work. Budget explicitly for everything else.
• Keep overhead and risk buffer separate, so you can explain both.
• Quote a range, state your assumptions, and re-estimate as unknowns are resolved.

Why are software estimates usually wrong?

Because people estimate the coding and forget everything around it, and because they give a single number for work they do not fully understand yet. A developer says “three days” for the happy path, then the edge cases, reviews, QA feedback, a deployment issue and two client calls turn it into seven.

The fix is not to “pad everything by 2x”. It is to make the hidden work visible and to be honest about uncertainty.

Step 1: How small should tasks be before you estimate?

Small enough that a developer can picture the code: two to three days at most. Large tasks hide unknowns. If a task is bigger than that, split it. If you cannot split it because nobody knows how it will work, that is a signal for a short time-boxed spike (a half-day or one-day investigation) before estimating.

For a typical feature I break work down along these lines:

• Data model and API endpoints
• UI screens and states, including loading, empty and error states
• Business rules and edge cases
• Integrations: email, payments, third-party APIs
• Permissions and roles
• Tests for the parts that matter most

Step 2: How do three-point estimates work?

For every task, I ask for three numbers instead of one:

• Optimistic (O): everything goes right
• Most likely (M): a normal amount of friction
• Pessimistic (P): things go wrong, within reason

Then I combine them with the PERT (Program Evaluation and Review Technique) formula:

Estimate = (O + 4 × M + P) / 6

It weights the most likely outcome, but a large gap between optimistic and pessimistic pulls the estimate up. That gap is useful on its own: it shows you exactly which tasks carry the risk.

A worked example: a leave management module

Here is a simplified version of a real kind of feature from HR software: employees request leave, managers approve it, and everyone gets notified. All numbers are in developer-days.

• Database schema and API: O = 2, M = 3, P = 6, so (2 + 12 + 6) / 6 = 3.3 days
• Request and approval UI: O = 3, M = 5, P = 9, so (3 + 20 + 9) / 6 = 5.3 days
• Leave balance rules and edge cases: O = 1, M = 2, P = 5, so (1 + 8 + 5) / 6 = 2.3 days
• Email and in-app notifications: O = 1, M = 2, P = 4, so (1 + 8 + 4) / 6 = 2.2 days

That gives 13.1 developer-days of build work.

Step 3: How much overhead should you add?

I add 20 to 30 percent for work that is not writing feature code: code review, QA and bug fixing, meetings and client feedback, and deployment. For a team that already works together on a familiar stack, 20 percent is usually enough. With a new client or a new stack I use 30 percent.

In the example, with 25 percent overhead: 13.1 × 1.25 = 16.4 developer-days.

Step 4: How big should the risk buffer be?

The risk buffer covers things nobody on the team can see yet, and I size it by how many unknowns the project has:

• 10 percent: familiar domain, familiar stack, clear requirements
• 15 to 20 percent: some unknowns, such as a new third-party integration
• 25 percent: new client, vague requirements or new technology

The example has a clear scope but a new notification system, so I use 15 percent: 16.4 × 1.15 = 18.9 developer-days.

I keep overhead and risk separate on purpose. When a client asks why the estimate is higher than the build work, I can explain each number instead of defending a mysterious multiplier.

Step 5: Why quote a range instead of a single number?

Because a single number sounds like a promise, and an estimate is a forecast. For the example, I would quote 17 to 21 developer-days, along with the assumptions behind it:

• Designs are approved before development starts.
• The client provides email provider credentials by the end of week one.
• Leave policies follow the rules agreed in the scoping call.
• Feedback rounds are limited to two per screen.

Assumptions turn scope changes into conversations instead of arguments. If an assumption breaks, the estimate changes, and everyone already agreed on why.

How do you keep an estimate accurate during the project?

Re-estimate at checkpoints. After the first week, the biggest unknowns are usually resolved, so I narrow the range and share the update. If a task is running long, I flag it the same day. A delay reported early is a planning problem. Reported on the deadline, it is a trust problem.

I also compare estimates with actual time after every project. Over a few projects this shows your team’s real bias. Most teams are consistently optimistic about UI work and edge cases.

Common estimation mistakes

• Estimating alone. The developer doing the work should be part of the estimate.
• Forgetting non-functional work: performance, accessibility, SEO, analytics, monitoring.
• Treating the estimate as a deadline the team must hit at any cost.
• Letting a client negotiate the estimate down without removing scope.

Frequently asked questions

About the author

I’m Hardik Gohil, a Web Team Lead and Full-Stack Developer at ProLance IT in Surat, India. I lead a team of 15+ developers and estimate client projects built with React, Next.js, Node.js and NestJS. If you are new to leading a team, read From Senior Developer to Team Lead: What Actually Changes.