How do you price work you have never done before?

A client asks what it will cost. You have never done exactly this before. Every number you say feels like a guess, because it is.

Here is how to make it a defensible guess rather than a nervous one.

Do not price the work. Price the uncertainty.#

The reason novel work feels unpriceable is that you are trying to estimate the whole thing at once. You cannot, and neither can anyone else — which is why fixed bids on unknown work are either padded until you lose the deal, or thin until you lose money.

Split it. Price the part you can see clearly at a fixed number, and refuse to price the part you cannot until it becomes visible.

The two-stage structure#

Stage one: a paid diagnostic. Small, fixed, short. Its deliverable is a written read on the real problem and a scoped proposal for stage two. Both sides get something even if you stop there — the client gets clarity they can act on with anyone, you get paid for the thinking.

Stage two: priced with knowledge. Now you have seen the data, met the team, found the constraint. The estimate is grounded rather than defensive.

Clients who refuse to pay for stage one are telling you something useful: they want certainty for free, which means they will want changes for free later too.

Estimate the shape, not the hours#

For the parts you can see, do not start from “how many days”. Start from what could go wrong:

• How many decision-makers must agree? Each one adds weeks, not hours.
• How clean is the data or the existing system? Assume worse than described — it always is.
• How many external dependencies? Anything you do not control is schedule risk you are absorbing.
• Has this client done a project like this before? Inexperienced clients need more of your time, and that time is real.

Those four questions move estimates more than the technical scope does.

Say the assumptions out loud, in the proposal#

Write what your number assumes. “Assumes one round of consolidated feedback.” “Assumes the existing analytics are trustworthy.” “Assumes API access by week two.”

This is not defensive paperwork. It converts a future argument into a priced change — because when an assumption breaks, you are not renegotiating trust, you are pointing at a line both of you agreed to.

What to do when you get it wrong#

You will. The professional move is to say so early, with the number, and with a recommendation — absorb it, reduce scope, or extend budget. Pick one and advocate for it.

Silently eating overruns teaches the client that your estimates are theatre. Silently cutting quality is worse. Either way you pay; the only question is whether you pay in money or in reputation.

The pattern#

Charge for the diagnosis. Estimate the visible part with named assumptions. Handle change as a priced decision, not a favour.

That is why every engagement I run starts as a paid diagnostic and a written scope before anything gets built — and why, when delivery needs a team, The League keeps scope and money visible to both sides rather than in someone’s inbox.