A quote written on a Friday afternoon
An enquiry comes in for a new website: around fifteen pages, a blog, a team section, a bookings integration and a newsletter signup. The owner opens last year's proposal for a similar site, adjusts the page count, adds a line for the booking system and sends it.
Three months later, the project is well over its hours. The booking integration took far longer than expected because of the provider's API. Content entry for fifteen pages with the client's late copy took days. The client needed four rounds of revisions on the homepage. None of this is new. The last three projects ran over in the same places, but nobody looked at why before writing the next quote.
Why quotes do not learn
- Time is logged against the project as a whole, or by person, not by component, so it is hard to see which parts overran.
- Proposals are written from the previous proposal, which carries the same blind spots forward.
- Overruns are explained away as "that client was difficult", so the pattern is not recognised.
- Non-build work, such as project management, content entry and revisions, is underestimated because it feels like overhead.
- Nobody sits down after a project to compare the quote with what happened.
The studio has years of evidence about what things really take. It is sitting in the time tracker, unread.
What underquoting costs
Projects lose money in the same places, again and again. Developers feel pressure to cut corners on projects that are already over. When the studio tries to quote more realistically, it has no evidence to justify the higher number, to the client or to itself. Good projects become stressful because they were sold at the wrong price.
The estimator we build
- A standard list of components is agreed: discovery, design per template, build per template, content entry per page, forms, integrations by type, e-commerce set-up, SEO migration, revisions, project management, launch.
- Time tracking going forward is tagged by component, using project tasks in your tool or tags in Harvest, Toggl or similar, so the data builds up without extra effort.
- Past projects are mapped to components as far as the old data allows, with a person helping where tasks were named loosely.
- For each component the estimator shows the range of actual hours across past projects, not just an average, with notes on what drove the high cases.
- When quoting, the owner picks the components for the new project and gets a suggested range per component and in total, based on your own history.
- After each project, a short comparison of quote against actual per component is produced automatically, so the history keeps improving.
| Component | Often underquoted because |
|---|---|
| Content entry | Clients supply content late and in pieces |
| Third-party integrations | APIs and provider accounts vary |
| Revisions | Stakeholders join late |
| Project management | Treated as overhead, not a line |
| SEO migration and redirects | Old site is bigger than expected |
The estimator suggests. The quote is still yours, and there will always be projects where your judgement about the client matters more than the history.
Quoting the next site
The next enquiry comes in. The owner selects the components and sees that the studio's booking integrations have ranged widely, that content entry per page has consistently taken longer than quoted, and that revisions on sites with several stakeholders run high. The quote includes those lines properly. The client may push back on price, but now there is evidence to explain it, and the project that goes ahead is priced for what it will take.
Are your quotes repeating old mistakes?
- Proposals are written by copying the last similar proposal.
- Projects regularly overrun in the same areas.
- Time is not logged by component.
- Nobody compares quotes with actuals after a project.
- Content entry and revisions are not priced as their own lines.