Milestone payments explained: stage the price by deliverable, not by date

By the WorkKitly Team · Last updated: November 2026 · 7 min read

A milestone payment is a slice of the project price that falls due when an agreed deliverable lands — not on a calendar date, and not at a percentage of effort nobody can measure. You invoice it when the client can see and check the thing the slice pays for: approved designs, a working staging build, the launch itself. The rule that makes the whole structure work is simple: never let completed, unpaid work run more than one milestone ahead of the money. Keep payments and deliverables locked together, and no single failure — yours, the client's, the project's — can cost either side more than one slice.

This guide picks up where our guide to freelance deposits and upfront payments leaves off. That one covers the upfront structures — half and half, thirds, everything in advance — and they are the right answer for most projects. Milestones are for the jobs too big or too long for two payments to protect anyone: the eight-week build, the three-month rebrand, the project where a deposit plus a final invoice would leave you financing weeks of work in the middle.

What counts as a milestone

A milestone is a deliverable the client can verify. The first full draft. The approved page designs. A working site on a staging address they can click through. The finished manuscript, delivered. Each one gives the client something concrete to point at and say "yes, that's the thing" — and that yes is what releases the payment.

Two things that are not milestones, however often they appear in contracts. A calendar date: "payment two due 1 December" releases money for nothing checkable, and if the work slips a week the date argues with reality. And a percentage of completion: nobody can inspect "60% of a website". Percentages describe effort, which only you can see; milestones describe artefacts, which both sides can.

One more test: the trigger must be within your control to produce. You deliver the staging build; the client's approval is their part, and the mechanics of that approval are covered below. A trigger that depends on events inside the client's organisation is a different problem entirely — see "what never to do".

How many milestones does a project need?

Scale the count to the project's length and risk — no further. A project of a few weeks rarely needs more than the deposits guide's shape: a deposit to start, the balance on delivery. Two payments, one argument possible, at the end.

A project running a month or two suits three or four stages: deposit, one or two deliverable milestones in the middle, final payment at handover. A project of a quarter or more can run on a monthly rhythm — but keep each month's payment tied to what that month delivered, not to the month itself. The calendar can set the tempo; the deliverable remains the trigger.

Resist slicing thinner than that. Every milestone costs you an invoice, a review window and sometimes a chase, and costs the client an approval. A stage worth a few percent of the fee buys admin, not protection. The count is right when losing any single stage would hurt but not sink you — that is the exposure each milestone exists to cap.

Sizing the slices

Front-weight the schedule slightly. The early stages should run a little ahead of the work completed — the deposit covers the first block, the design milestone a little more than the designs alone — so that at every point in the project, the money received covers the work delivered, with a small margin. The moment payments trail the work, you are lending the client money at zero interest and calling it a schedule.

The final slice needs the opposite care. Keep it meaningful: often around a fifth of the price. It is your reason to finish the polish and the handover promptly, and the client knowing it exists is part of what keeps the ending orderly. But don't let it swell into the largest stage either — a final payment that dwarfs the rest makes the client feel the project is held hostage at exactly the moment you both want goodwill, and it concentrates your risk at the point where you have the least work left to trade. Exact percentages are a judgement for the shape of the job; the shape itself — front-weighted, meaningful final — is the principle.

None of this decides the price itself, only how it arrives. If the total is still unsettled, build it first with the project price calculator, then cut it into stages — the deposit and milestone schedule calculator builds the stage table from the price in this guide’s shapes, with the running totals and the exposure of each worked out for you.

A worked example: $6,000 over eight weeks

A website build, fixed at $6,000, running eight weeks. Four stages:

Read the last column against the work. After the designs are approved, you hold 55% of the fee for roughly the first third of the effort — ahead, as intended. After staging, 80% paid for a site that exists and can be reviewed. If the project had died at that point, you would hold 80% of the price for about 80% of the work, and the client would hold a working staging site: a bad ending, but a fair one. And the final $1,200 is large enough to make launch day a priority for both sides, without being the ransom the whole project hangs on.

Approval: how a milestone gets signed off

A milestone is approved in writing. That does not need ceremony — an email saying "approved, go ahead" is a sign-off — but it does need to exist, because the approval is the invoice's trigger and, later, the record that the deliverable was accepted as agreed. Verbal approval in a call, remembered differently by two people, is how milestone disputes start.

Give the client a stated review window in the agreement: a set number of days to review the deliverable and respond. What silence means at the end of that window is whatever your contract says it means — no more, no less. If the agreement states that no response within the window counts as acceptance, then it does, and you invoice. If it doesn't say that, silence is just silence, and the professional move is a polite chase, not an invoice built on an assumption. Getting these clauses right is the work of our guide to freelance contract basics; the milestone schedule belongs in the same document as the scope it pays for.

And if a milestone invoice is not paid on its terms, the work pauses. Politely, without drama — and crucially, as the agreement already provides, so the pause is the schedule working as designed rather than a threat invented mid-project. The terms themselves — due dates, what happens when they pass — are the subject of our guide to freelance payment terms. Whatever you do, do not start the next stage while the previous stage's invoice sits unpaid. That is the opening rule again: one milestone of unpaid work is the maximum exposure the structure allows.

What never to do

Start the next stage on a promise. "Accounts are processing it" may even be true, but a promise is not a payment, and beginning stage three anyway converts your protection into a favour already given. The schedule only protects you if it is followed when following it is slightly awkward.

Let the final slice shrink to a token. A 5% final payment makes launch the cheapest thing in the world for a distracted client to postpone — and quietly teaches you to deprioritise finishing, too. If the last stage isn't worth real money to both sides, the project's ending will drag.

Tie a milestone to something you can't see. "Payment on our funding landing", "after our board meets", "when the new site starts selling" — these are events inside the client's world, with no date you can verify and no artefact you can check. You don't have a milestone; you have a hope wearing one's clothes. Insist on a deliverable, or on a date certain as a backstop, before the work starts.

When the scope changes mid-project

It will. The rule is that a change never gets silently absorbed into the current milestone — that is how a $6,000 project becomes $8,000 of work paid at the old stages. A change becomes one of two things: a new milestone added to the schedule, with its own deliverable and amount, or a written amendment that re-prices the affected stage before the changed work begins. Either way it is priced and agreed in writing first. The deliverables your milestones tie to come from the scope document — build it with the scope of work generator — and changes re-enter through the same document, not through a chat message that says "while you're at it…".

Questions

Related: the chain the milestones sit in

Start with the deposits guide for the upfront decision, price the whole job with the project price calculator, and write the stages into the agreement beside the scope — contract basics covers the clauses, and the scope of work generator builds the deliverable list each milestone ties to. Milestones are simply where those documents meet the calendar: money and work, arriving together, all the way to launch.