There's a question every web agency director has heard at least once during a project review: "How could we have been so far off the quote?" The project was supposed to take 120 hours, it consumed 185. The planned 35% margin turned into an actual margin of 8%. And the worst part is that nobody noticed until the end.
This scenario isn't an extreme case. It's the daily reality of the majority of web and communication agencies. Industry studies show that 65 to 75% of web projects exceed their initial estimate. Not because the teams are incompetent, but because the estimation method itself is flawed.
This article gives you a concrete method, based on your historical data, to build reliable quotes. No abstract theory: tables, coefficients, reproducible steps.
Why agency quotes are systematically underestimated
Before fixing the problem, you need to understand the mechanisms. Quote underestimation isn't an accident. It's the result of cognitive biases, commercial pressures, and methodological gaps that compound.
The developer's optimism bias
When a developer estimates a task, they visualize the ideal scenario: the brief is clear, the design is locked, the API works on the first try, the client approves without feedback. This scenario never happens. On average, developers underestimate tasks by 25 to 40% according to the Standish Group. This isn't bad faith -- it's a documented cognitive bias in psychology known as the "planning fallacy."
The commercial pressure of "market price"
The sales director knows the client received three quotes. They also know the competitor charges 15% less. So they "adjust" the estimate. They remove the 8 hours of QA planned by the developer. They reduce project management from 20% to 10%. They eliminate the buffer. The quote is competitive. The project is signed. And six weeks later, the unbudgeted hours are very much there, invisible in any line of the quote, but very real in the team's workload.
The absence of usable historical data
This is the fundamental problem. Most agencies have no structured database of their past projects. Actual times aren't tracked, or they're tracked in an Excel file that nobody consults. Without data, every quote is an estimate "by gut feeling" -- a divination exercise dressed up as technical costing.
Key figure: According to an analysis of 200 web agency projects, the average gap between quoted time and actual time is +34%. In other words, a project quoted at 100 hours consumes an average of 134.
Structural omissions
Certain tasks never appear in quotes because they're considered "included" or "obvious." Yet they consume real time:
- Project management (client exchanges, meetings, reports)
- Internal QA and bug fixing
- Deployment and server configuration
- Content migration and integration of final copy
- Mockup revisions after the initial brief
These tasks typically represent 25 to 35% of a project's total time. If they're not in the quote, the margin is eaten before production has even started.
The historical data method: using actual times from past projects
The best estimate doesn't come from the best expert. It comes from relying on real data. The historical data method involves building your quotes from what your past projects taught you -- not from what you hope.
Step 1: Collect actual times from your last 10-20 projects
Start by gathering data from your completed projects. For each project, you need four pieces of information:
- The project type (landing page, brochure site, e-commerce, web application)
- The total quoted time (in hours)
- The total actual time (in hours)
- The breakdown by item (design, front-end development, back-end development, project management, QA)
If you're not yet tracking actual project times, now is the time to start. Without this data, you're flying blind. Even an approximate tracking over the next three months will give you a usable baseline.
Step 2: Calculate the average quoted/actual ratio by project type
For each project type, divide actual time by quoted time. You get an overrun coefficient.
Example: You've completed 5 brochure sites over the last 12 months. Quoted times were 80, 95, 110, 75, and 120 hours. Actual times: 105, 130, 140, 95, and 165 hours. The average ratio is (105+130+140+95+165) / (80+95+110+75+120) = 635/480 = 1.32. Your brochure sites consume an average of 32% more than what you quote.
Step 3: Identify the most underestimated items
The overall ratio is useful, but the real improvement lever is in the breakdown by item. By decomposing, you'll probably discover that:
- Back-end development is the best-estimated item (developers know how to evaluate pure technical tasks)
- Project management is systematically underestimated (client exchanges always take more time than expected)
- QA and fixes are often absent or token in quotes
Key takeaway: Don't try to correct the overall estimate. Correct each item individually. An overall coefficient masks the real problems.
Step 4: Apply the ratios to future quotes
Once your ratios are calculated, integrate them into your quoting process. If your developer estimates 40 hours of front-end and your historical ratio for this item is 1.25, quote 50 hours. This isn't "padding" -- it's precision.
Margin coefficients to apply by service type
Beyond the overall historical ratio, it's useful to apply specific coefficients by activity type. These coefficients account for the inherent uncertainties of each item and the implicit tasks that are never quoted.
Here's a reference coefficient table, calibrated from web agency project data. Adapt it to your own history.
| Item | Recommended coefficient | Justification |
|---|---|---|
| Art direction / UX | x 1.20 | Client iterations, creative exploration |
| UI mockups / Web design | x 1.15 | Client feedback on mockups, adjustments |
| Front-end integration | x 1.15 | Responsive, edge cases, browser compatibility |
| Back-end development | x 1.10 | Generally the best-estimated item |
| Project management | x 1.30 | Meetings, follow-ups, coordination, reporting |
| QA and fixes | x 1.25 | Late-discovered bugs, post-delivery feedback |
| Deployment and launch | x 1.20 | Server configuration, DNS, certificates, adjustments |
| Content and editorial integration | x 1.35 | Waiting for client content, reformatting, adaptation |
Concrete example: A brochure site is estimated by the team at 95 raw hours. After applying coefficients: UX 12h x 1.20 = 14.4h, mockups 20h x 1.15 = 23h, front-end 25h x 1.15 = 28.75h, back-end 15h x 1.10 = 16.5h, project management 10h x 1.30 = 13h, QA 8h x 1.25 = 10h, deployment 5h x 1.20 = 6h. Adjusted total: 111.65 hours instead of 95. A 17.5% difference -- exactly the margin you would have lost without these coefficients.
Why these coefficients aren't "padding"
A common objection: "If we apply these coefficients, our quotes will be too expensive and we'll lose deals." This reasoning confuses selling price with cost price. The coefficients don't increase the price -- they reveal the true cost. If you quote 95 hours but consume 112, you bill 95 hours and give away 17. It's a gift you're making to your client, at the expense of your profitability.
The real issue isn't to pad quotes, but to stop underestimating them. And for projects where competition forces a low price, at least you know exactly how much you're investing -- and you can decide in full knowledge whether to do it or not.
Building a time reference by project type
The culmination of this method is building an internal reference framework: a document that centralizes your time ranges by project type. This framework becomes the basis for all your quotes and enables consistent estimates across teams.
The reference table by project type
Here's an indicative reference framework, to be adapted according to your positioning and tech stack. The ranges already include margin coefficients.
| Project type | Art direction | Mockups | Front-end | Back-end | Project management | QA | Total range |
|---|---|---|---|---|---|---|---|
| Simple landing page | 4-8h | 6-12h | 8-16h | 4-8h | 4-8h | 3-6h | 29-58h |
| Brochure site (5-10 pages) | 10-18h | 15-30h | 20-40h | 12-25h | 10-20h | 6-12h | 73-145h |
| Corporate site (20+ pages, multilingual) | 18-30h | 25-45h | 35-60h | 25-45h | 18-35h | 10-20h | 131-235h |
| E-commerce (catalog < 500 refs) | 15-25h | 20-40h | 30-55h | 40-75h | 20-40h | 12-25h | 137-260h |
| Custom web application | 20-40h | 25-50h | 40-80h | 60-150h | 25-50h | 15-35h | 185-405h |
Key takeaway: These ranges don't replace a detailed estimate. They serve as guardrails: if your quote for a brochure site comes in at 50 hours, that's a warning signal. If your e-commerce exceeds 300 hours, you need to verify that the scope justifies it.
How to build your own reference in 4 steps
1. Categorize your past projects. Review your last 15 to 20 projects and classify them by type. Don't create too many categories -- 4 to 6 are enough. The goal is to have at least 3 projects per category for meaningful averages.
2. Collect actual times by item. For each project, break down the actual time by major activity (design, front-end dev, back-end dev, project management, QA). If you don't have this level of detail, estimate the breakdown retroactively with the relevant project managers.
3. Calculate medians by item and by type. Prefer the median over the mean -- it's less sensitive to outliers. A project that overran because of a difficult client shouldn't skew your entire reference framework.
4. Update the reference every 6 months. Your team progresses, your tools evolve, your tech stack changes. A frozen reference loses its relevance within 12 months. Integrate new data and recalculate ranges twice a year.
Integrating the reference into the sales process
The reference framework is useless if it stays in a shared folder that nobody opens. It must become a daily tool in the sales cycle.
During the client brief, the salesperson uses the reference to give the client a budget range from the first meeting. "For a brochure site with your scope, we're generally between 100 and 140 hours, or 8,000 to 11,200 euros excl. tax." This transparency builds trust and avoids surprises.
During detailed costing, the project manager uses the reference as a starting point and adjusts each item based on the project's specific requirements. The reference provides the floor and ceiling; the project manager's expertise refines the position within the range.
During the post-project debrief, actual times are compared to the reference. If the project fell within the range, the reference is validated. If not, the gap is analyzed and adjustments are made. It's a continuous improvement loop.
Turning your data into a competitive advantage
The method described in this article is nothing revolutionary. It rests on a simple principle: measure reality to predict the future. But in an industry where the majority of agencies estimate "by gut feeling," this discipline gives you a considerable advantage.
An agency that knows its brochure sites consume an average of 115 hours, with a standard deviation of 20 hours, can propose a 120-hour quote with confidence. They know their margin is protected in 70% of cases. And for the remaining 30%, they've anticipated an overrun scenario and planned the management mechanisms -- amendment, milestone-based billing, or automatic alert when consumption reaches 80% of budget.
Conversely, an agency that estimates "by gut feeling" signs projects with a theoretical margin of 35% and finishes the year with an actual margin of 12%. The difference is 23 profitability points evaporated -- or, for an agency billing 500,000 euros per year, 115,000 euros of lost margin.
Key figure: A 15% improvement in quote accuracy translates on average to an 8 to 12 percentage point increase in net margin on projects. For a 10-person agency, that represents 40,000 to 80,000 euros per year.
The first step is always the same: start measuring the actual time of your projects. If you're not doing it yet, it's the absolute priority. Even imperfect tracking over three months will give you infinitely more reliable data than your best project manager's intuition.
If you're already facing recurring gaps between time spent and time quoted, you know the problem is real. If you identify projects that seemed profitable but weren't, you know the data is missing. The method is here. All that's left is to apply it.
Time tracking tools designed for web agencies make this approach systematic and automatic. But the tool without the method is useless. Start with the method. The tool will come naturally when the volume of data to process exceeds your manual capabilities.