Milestones That Actually Work

Milestones exist so neither party carries the whole risk. Split badly, they do the opposite: they create arguments about whether a stage is finished, at the exact moment money is meant to move.

Each milestone needs a visible output

The test is simple. Can the client look at something and say yes, that exists? Design complete is arguable. Five approved screens in Figma is not.

Bad milestones describe effort. Good ones describe artefacts.

Three to five, not ten

Ten milestones on a four-week project means ten approval conversations, and each one is an opportunity to stall. Three or four is usually right.

Front-load a small one

Make the first milestone small and quick, even trivially so. It gets both sides through the full cycle of fund, deliver, approve, release while the stakes are low. You learn how the other person communicates before there is real money at risk.

Never leave the largest until last

If sixty percent of the fee sits in the final milestone, the freelancer is carrying most of the risk right until the end, and the client holds all the leverage. Weight them evenly, or slightly front-load.

The final milestone should be small enough that neither party is tempted to behave badly over it.

Write the acceptance criteria into the title

A milestone called Homepage is a future argument. A milestone called Homepage, desktop and mobile, approved copy, no placeholder images is a contract.

Fund before work starts

A milestone that is agreed but unfunded is a promise. A funded milestone is a commitment. On QwikJob you can see which is which on the contract, and freelancers should check before writing a line of code.