Pricing work you've never done: the spread matters more than the rate
No credible table prices a deliverable, and the real unknown is hours anyway. How to estimate an unfamiliar job, and when to sell discovery instead.
A large share of what freelancers type into a search box is a price for a specific thing: what a website costs, what a brand identity goes for, what to charge for a CMS migration. The pages ranking for those questions answer with a confident range, and almost none say where it came from.
Two published rate figures have any method behind them. freelancermap's annual study reports an average hourly rate of €103 in 2026, from 5,400-plus respondents in the DACH region, skewed heavily toward IT and engineering contractors. IPSE's UK average day rates are built on a stated method, around 1,500 respondents across the four quarters of 2024, and the figures are members-only, so you cannot read them. Neither Upwork nor Fiverr publishes a rate-by-discipline table with a documented methodology. Everything else ranking for "average rate for X" is unsourced, much of it recycled from other unsourced pages.
That gap is real, and it is not the gap you think it is. Even an honest table would give you a price per hour, and what a client asks for is a price for a job. Between the two sits a number nobody can publish on your behalf: how many hours this work will take you, with this client, at your current familiarity with it.
The unknown is the hour count, not the price
Your floor is knowable. Target profit, tax reserve, business costs and an honest billable percentage produce a rate below which the work is a hobby, and computing that floor and then choosing a pricing model is arithmetic you do once a year.
The floor tells you what an hour has to earn. It says nothing about how many hours there will be. On work you have done twenty times that silence costs nothing, because the hour count is already in your head. On work you have never done it is the whole problem, and precision on the rate side does not offset a large error on the volume side. The question is not what people charge for this, but how you size a job whose shape you cannot see yet.
No record, no reference class, no estimate
The most reliable predictor of how long something takes you is how long similar things took you. That is the only estimating method with a track record: find the closest jobs you actually completed, take what those cost in hours, and adjust from there rather than reasoning forward from the brief.
The best evidence on skipping that step comes from a field with far better records than freelancing. Flyvbjerg's survey of transport infrastructure found average cost overruns of 44.7% for rail, 33.8% for bridges and tunnels, and 20.4% for roads, across a 70-year span in which forecast accuracy did not improve. Those are megaprojects with professional estimators, so do not transplant the percentages. Transplant the mechanism: forecasts built forward from a project's specifics run low, in the same direction, for decades, and experience alone does not correct it.
The consequence for anyone quoting unfamiliar work is uncomfortable: a freelancer who does not record hours has no reference class. Not a poor one, none. They can recall that last year's rebuild felt like three weeks, and feeling is exactly the input shown to run low. The archive that makes estimation possible is boring: hours logged against a project, next to the fee, so the two can be divided. That division gives you the effective hourly rate, whose second use, after telling you whether a finished project paid, is telling you what the next of its kind will cost.
Time tracking is therefore an estimating instrument, which changes what you want from it. Harvest's $9 per seat per month buys a stopwatch and reporting. Estimation needs hours attached to a project that also holds the fee, the scope and the change orders, so a finished job becomes a data point, not a memory. That is the axis the Harvest alternative comparison is built on, and why billable-by-default time logging matters more than timer ergonomics.
Eight small guesses beat one large one, and the error runs the safe way
Where the reference class is thin because the job really is new, decomposition is what remains. Estimating one large unknown produces a number biased low: you picture the work going well, because the version you can picture is the one without problems you have not met yet. Estimating eight small components and summing produces a number biased high, since each gets its own allowance for going wrong and eight allowances exceed any realistic bad week. Both estimates are wrong. Only one is wrong in a direction you survive.
Take a CMS migration you have never run, as an illustration rather than observed data. The lump-sum instinct says three weeks, call it 90 hours. Now break it, and give each piece an optimistic and a pessimistic figure. Content audit and inventory, 6 hours against 14. Template mapping, 8 against 20. Template build, 20 against 40. Migration script and dry runs, 10 against 30. Manual cleanup of what the script mangles, 6 against 24. Redirects and a search-parity check, 4 against 12. Two rounds of client review, 6 against 18. Launch, monitoring and the fixes that follow, 4 against 12.
The optimistic column sums to 64 hours, the pessimistic to 170, midpoint 117. The lump-sum guess of 90 was 23% below the midpoint of your own decomposed estimate, made by the same person about the same job ten minutes earlier. It also produced a spread, 64 to 170, which turns out to be the more useful output.
The hours that were never in the brief
Every component above is named in the deliverable, and unfamiliar jobs rarely overrun on those. They overrun on four things in no brief.
First, revision rounds are unbounded unless someone bounds them; a fixed fee with an open revision count is an hourly engagement where you agreed not to send the second invoice. Second, decisions waiting on the client: a day you cannot proceed because copy is unapproved is not a day off, it is a day your schedule absorbs and your fee does not. Third, dependencies you do not control, from the client's IT team granting access to a vendor answering a ticket. Fourth, and largest on new work, the discovery you have not done: components you could not list because you do not know they exist.
The first three are estimable once you name them. The fourth is not, by definition, and that asymmetry decides everything below. Most surface early if you ask well before accepting, and the five questions that predict whether a project will be profitable are mostly about who decides and how many of them there are.
Contingency with names in it
The usual handling is a flat percentage, twenty or thirty on a bad feeling. That is anxiety expressed in currency, and it fails twice. Too small and it vanishes into the first surprise. Large enough to be safe and it is a number you cannot defend, so you shave it when a client pushes back.
A contingency sized to named risks behaves differently, because a named risk has three commercial responses. Price it: the migration script may hit undocumented custom fields, allow 12 hours. Cap it: two revision rounds included, further rounds at a stated change-order rate. Or exclude it: image re-licensing is out of scope and quoted separately. Each is a sentence a client can read and agree to, and each converts an unknown into a term.
A risk you cannot name has none of those responses, since you cannot price, cap or exclude what you cannot describe. A small unnamed portion is covered by a modest allowance. Where it dominates, you do not have an estimation problem that a percentage fixes. You have a research problem, and the correct commercial answer is to sell the research.
Matching the quote to how much you actually know
The spread bands come from the arithmetic in the closing section; the contingency figures are recommendations, not measurements. Read the left column against the job in front of you.
What you can honestly say | Spread (pessimistic ÷ optimistic) | Price it | Contingency | What goes in the proposal |
|---|---|---|---|---|
Five or more times, with logged hours on each | Under 1.3 | Fixed price | 10–15%, against named risks | Revision cap, exclusions, change-order rate |
Two or three times, but this client and stack are new | 1.3–1.6 | Fixed price | 20%, weighted to client-dependency risk | As above, plus dated client dependencies and slip consequences |
Something adjacent; core familiar, one component is not | 1.6–2.0 | Fixed on the familiar part, capped allowance on the rest | Only on the unknown component | Two fee lines, so the client sees which half carries the risk |
Never done it, but you can list the components and name the unknowns | 2.0–3.0 | Paid discovery, then a fixed price for the build | Discovery is the contingency | Discovery deliverable defined, plus a validity date on the build estimate |
Never done it and cannot list the components | Above 3, or unmeasurable | Time and materials with a not-to-exceed, or decline | No fixed number is honest here | A rate, a ceiling, and a review point in hours |
The middle row is the one people skip. It prices the part you understand at full confidence instead of discounting the whole job to cover the part you don't.
Paid discovery is a deliverable, not an apology
Discovery is a small fixed-fee engagement, a few days, ending in a written artifact: the decomposed estimate, the named risks, the technical findings, and a fixed price for the build with an expiry date. The client buys a decision-ready plan. You buy a reference class for a job you have never done, at their expense rather than yours.
Price it against your floor, small enough to read as a step rather than a commitment. A discovery engagement that produces a document the client could hand to another supplier is a real deliverable, which is why it converts: nobody who paid for a plan wants to re-explain the project to someone new. What belongs in a proposal and what to leave out applies to both documents, and either comes out of the proposal generator or, where the build estimate needs a validity date on its line items, the quote generator. Both run in the browser, no signup, no watermark.
Then there is the client who refuses. Occasionally that is an honest budget constraint. More often it is information: this buyer expects the supplier to absorb the unknowns, has not decided what they want, or is collecting free scoping from three freelancers. Each is a project that overruns, learned for the price of one declined proposal instead of forty unbilled hours.
The spread at which a fixed price stops being honest
Take your optimistic hours, your pessimistic hours, and divide the second by the first. Call it the spread, R.
A fixed price is defensible only if it still clears your floor in the pessimistic case, so the fee you must quote is your floor rate times the pessimistic hours. The fee a client thinks is fair is your floor rate times the likely hours, roughly the midpoint. Divide the first by the second and the rate cancels out, leaving 2R ÷ (R + 1), a markup over the likely-case price of (R − 1) ÷ (R + 1). Your floor never enters it. The spread is the only input.
Run it. At R = 1.5 the premium is 0.5 ÷ 2.5, or 20%, which clients pay without argument. At R = 2 it is 1 ÷ 3, or 33%, and you are now in a conversation. At R = 3 it is 2 ÷ 4, a 50% markup, and no informed buyer knowingly pays half again for uncertainty you introduced. So you shave it, and the moment you shave it you carry the estimation risk for free.
The rule: at a spread of 2 or more, a fixed price is not defensible, and discovery or time-and-materials is the correct answer. The migration above ran 170 ÷ 64, a spread of 2.66 and a required premium of 45%. Do not quote it fixed. Spend twelve hours on discovery instead, running the script against real content and inventorying the templates, and the two widest components collapse. Recompute: 80 optimistic, 150 pessimistic, R = 1.875, premium 30%. Now it is quotable, and the twelve hours were billed.
One caution. If your optimistic and pessimistic figures were ten minutes apart in the making, R comes out near 1 and the rule waves through a fixed price on a job you know nothing about. The spread is diagnostic only when the pessimistic number was built by naming things that actually go wrong, which returns the argument to the record. A reference class is what makes a pessimistic case honest rather than decorative, and the number that closes the loop is the effective hourly rate the finished job returned, set against the estimate that priced it.
In Worklyn, a project holds its budget and its logged hours together, so the estimate you quoted and the hours it took end up in one place, which is where the next estimate comes from.