How do you estimate a project you have never done before?

Run the smallest real version of it first and measure what that cost. Price the familiar parts at a rate you can defend, and sell the unfamiliar part as a discovery step whose deliverable is the measurement.

What is a paid discovery phase?

A short priced piece of work whose output is information rather than a deliverable. It ends in a written measurement: what the process costs to run once, what each extra unit costs, and the re-run rate.

Should you pad an estimate to cover unknown work?

Padding protects the margin on one job and leaves you no reusable number for the next. It hides which part you were unsure about, so the client cannot help reduce that risk.

How big should a pilot be before quoting the full project?

Small enough to be cheap and complete enough to touch every stage of the process, including publishing. On one rebuild a single trivial change followed to production revealed that publishing was a branch push.

Why do fixed price projects lose money?

Because rework and approvals are not on the estimate. Rework happens when the first output misses a standard nobody encoded. Approvals sit with people who were never in the kickoff. Neither gets a line.

Scoping Work You Have Never Done Before

Q: What should you measure during a pilot?

The fixed cost of running the process once, the marginal cost of each extra unit, and the re-run rate. Image generation carries roughly 25k to 28k tokens of overhead per call plus about 5k per extra image, so a batch of one misleads at every other size.

Work you have never done before cannot be estimated from the outside. The way to price it is to buy the information first: run the smallest real version end to end, measure what it cost, then quote the rest off the measurement. That purchase is a scoping step with its own price and its own deliverable.

Padding protects the margin and teaches you nothing. The next job of the same kind starts from the same blank.

Why do estimates fail on unfamiliar work?

The estimate gets assembled out of the parts you recognise, and the unfamiliar part gets a placeholder. That placeholder usually decides the schedule.

The worst version reads like a task and behaves like a system. We built an internal product end to end. Design, build, payments, fulfilment, all shipped. The one question deferred to launch was how the first hundred people would arrive. It was a system needing months of lead time rather than a task, and it earned nothing across its life.

Five lines that get one number on an estimate and behave like several:

Line on the estimate	What it actually is	What the number missed
Launch it	A distribution system with months of lead time	Nobody arrives because the product exists
Migrate the content	A record by record remap	Roughly one record in six was irregular
Get it signed off	Approvals owned outside the team	Two gates nobody listed. The date moved twice
Connect the tools	A chain with a ceiling and an ID under it	A free tier capped at 300 sends a day
Generate the creative	A measured pass rate	2 of 3 images on style without a reference image

How do you buy the information before committing to a number?

Run the smallest version that touches every stage of the real process. On an inherited enterprise rebuild we made one trivial visible change and followed it to production first. That is how we found publishing was a branch push, and that the obvious deploy command would have gone over the live site.

Coverage matters more than size. A test that skips publishing tells you nothing about publishing. The programme that later shipped 255 pages had already put out a batch of seven as one release. A small real release beats an estimate from outside.

What do you measure on the small version?

Two numbers, kept apart. The fixed cost of running the process once, and the marginal cost of each extra unit. Image generation carries roughly 25k to 28k tokens of fixed overhead per call plus about 5k per extra image, so a per-image cost from a batch of one is wrong at every other size.

Then the re-run rate, which sets the schedule. Compositing a product screen onto a generated phone produced zero usable images. Generating the screen into the scene in one pass produced three of three. Forcing right-hand drive took five attempts, because the model carries a strong left-hand-drive prior.

How do you quote it without lying or padding?

Split the number. Parts you have done before get priced at a rate you can defend. The part you have not gets a discovery step whose deliverable is the measurement in writing, with its assumptions.

Then put a name against each assumption. If the quote assumes approvals inside a week, name who approves. Asking who can stop this rather than who is involved surfaces the gates that move dates, the argument in name every gate in week one.

One line on every estimate is a system pretending to be a task. On ours it was the word launch.

What if the small version costs more than the client will pay?

You found out in week one for the price of a small release. The alternative is finding out in the rework. A batch of twenty AI-written posts came back structurally clean and missed the documented standard completely: no first-party data, no tables, no FAQs, no schema, around 595 words against a bar of 1,000 to 1,400. Nobody had priced the repair.

Both engagements are written up: what a CMS migration actually costs and the product that shipped to nobody.