Underquoting a project is one of the fastest ways to turn a good client into a bad month. Most underquotes don't come from a bad hourly rate, they come from a bad estimate of scope, timeline, or the buffer needed for the inevitable revision round. Here's a set of tools and reference concepts worth having in your quoting process before the number goes out the door.
PERT estimation
Program Evaluation and Review Technique, or PERT, is a decades-old estimation method that asks for three numbers per task, an optimistic estimate, a pessimistic estimate, and a most-likely estimate, then blends them into a weighted average that's more realistic than a single guess. It was originally built for large defense and engineering projects but scales down fine to a single freelance quote. Wikipedia's entry on PERT covers the formula and its origins if you want the full method rather than a summary.
Toggl Track for baseline time data
Before you can estimate a new project accurately, it helps to know how long similar work actually took you last time, not how long you assumed it would take. Toggl Track is a straightforward time tracker that a lot of freelancers use specifically to build that baseline over a few projects, so future quotes are grounded in real data instead of optimism.
Clockify as a free alternative
Clockify does largely the same job as Toggl with a more generous free tier, which makes it a reasonable starting point if you're not ready to pay for time tracking yet but want to start collecting the same baseline data.
Asana or Trello for breaking scope into tasks
Estimation accuracy improves a lot once a project is broken into discrete tasks rather than estimated as one lump. Asana and Trello both work fine for this: the point isn't the specific tool, it's forcing yourself to list every deliverable separately so nothing gets silently absorbed into "and other stuff" when you're building the number.
A contingency buffer, always
Whatever method you use to get a base estimate, add a contingency percentage on top, typically somewhere in the 10 to 20 percent range depending on how well-defined the scope actually is. Revision rounds, scope clarification calls, and client-side delays are close to universal, and a quote with zero buffer for them is a quote that's already wrong before the project starts.
Function point analysis for larger, more technical scopes
For bigger technical projects where task lists alone don't capture complexity well, function point analysis is worth knowing about. It estimates effort based on the number and complexity of inputs, outputs, and data structures a system needs to handle, rather than just a list of tasks and hours. It's more setup than most freelance projects need, but for a larger app-development quote, it can surface complexity that a simple task list glosses over, particularly around data validation and integration points that don't map cleanly to a single deliverable line.
Historical variance, not just historical averages
Baseline time data from Toggl or Clockify tells you the average time a task type has taken you in the past, but the variance around that average matters just as much. If a task type has taken anywhere from four to fourteen hours across past projects, quoting off the average alone understates your real risk on any individual project. Tracking the range, not just the mean, gives a more honest picture of how much contingency a specific task type actually needs.
Client-side dependencies as their own line item
Delays caused by the client, slow feedback, late asset delivery, delayed approvals, are one of the most common reasons an accurately scoped project still runs over its estimated timeline. Building an explicit assumption into your estimate ("client feedback turnaround assumed at 2 business days") makes it possible to point to that assumption later if a project slips because the client took two weeks to respond instead, rather than absorbing the delay silently as if it were your estimation error.
Revisiting estimates mid-project, not just at the start
An estimate made before a project starts is a snapshot based on incomplete information. Once work is underway and scope clarifies, it's worth revisiting the estimate against actual hours logged so far, rather than treating the original number as fixed regardless of what's been learned. Catching a scope creep pattern halfway through a project, while there's still room to have a change-order conversation with the client, is far better than discovering it only once the project is fully over budget.
Notion or a plain spreadsheet as a lightweight alternative
Not every freelancer needs dedicated project management software. Notion works fine as a lightweight alternative to Asana or Trello if you want a single flexible workspace for task breakdowns, estimates, and client notes together rather than separate tools for each. The specific software matters less than actually doing the breakdown step at all, since that's where most of the estimation accuracy comes from, not from which app holds the list.
Comparing quoted estimate to actual hours after every project
The single highest-leverage habit in this whole process is closing the loop: once a project wraps, compare the original estimate to actual hours logged, task by task, not just in aggregate. This is how baseline time data (the input to step one above) actually improves over time. Skipping this step means every future estimate is still based on the same level of guesswork as the very first one you ever made, regardless of how many projects you've since completed.
Putting it together in one place
Once you have baseline hourly data and a task breakdown, running it through a dedicated estimator saves you from rebuilding the same spreadsheet formula every time. EvvyTools' project estimator takes task-based inputs, an hourly rate, and a contingency buffer, and includes a PERT estimation mode along with automatic delivery date calculation, so the output is a number and a timeline you can actually hand to a client, not just a total.
Building a personal rate card from past estimates
Over enough projects, task-level baseline data can be organized into a personal rate card, average hours and typical variance per task type, that speeds up future estimating dramatically compared to rebuilding the estimate from scratch every time. This is really just the accumulated output of steps one through eight applied repeatedly, but it's worth treating as a deliberate artifact you maintain, rather than a side effect you never actually look back at.
The other half of getting paid what you quoted
Estimating the project correctly only gets you a fair quote. Actually collecting on it, especially if any part of your income is commission-based rather than flat project fees, depends on a different set of mechanics entirely. There's a longer breakdown of how tiered sales commission actually gets calculated, covering tier brackets, accelerators, and draws, worth reading if estimating and quoting is only part of how you get paid.
A quick recap
The core habit underneath all of this is the same regardless of which specific tool you use: break scope into discrete tasks, ground time estimates in real historical data instead of optimism, add a genuine contingency buffer, and compare estimate to actual once the project closes. The specific software is replaceable. The discipline of doing all four steps consistently is what actually improves quoting accuracy over time.
Try EvvyTools' project estimator directly, free and without an account.
Top comments (0)