How to Structure Milestone Payments for an AI Project (Get Paid on Proof, Not on Promises)

To structure milestone payments for an AI project, split the fee into a few payments and attach each one to a visible, checkable event: the project starts, the client sees it working, the client accepts it. Do not attach payments to dates, because the client can stall a date, and do not attach them to hours, because hours are an argument. A payment that unlocks when the client approves a working preview is one nobody has to chase.

This protects both sides. The client never pays for something they cannot see, which is the real fear behind most hesitation on AI work. You never deliver the whole thing on trust and then wait. The number of payments is not the point; the proof behind each one is.

Payments tied to dates ("first of the month") feel tidy but they break the moment the project slips for any reason, including the client being slow to send material. Then you are asking for money for work they cannot yet see, and they are right to resist.

Payments tied to hours turn every invoice into a negotiation about whether it really took that long. With AI builds that is especially bad, because the speed of the tool means clients assume the work was easy and push back on the time. I price AI work on the outcome, as covered in why I stopped charging hourly for AI builds, and the payment schedule follows the same logic: pay for outcomes you can point at.

Start is the deposit. It commits the client and covers the work of getting going. It is paid before any work begins, and the project does not start until it clears.

Show is the payment that matters most, and the one people skip. When you have the core job working on a link the client can open, with their own example data in it, you request the next payment. It proves progress, gives the client a real look before most of the money is spent, and gives you cash flow through the middle of the project instead of one big wait at the end. How to demo a Claude Code build to a client covers how to run that preview so it gets approved.

Ship is paid on acceptance, before you hand over the final access. The finished build is tested against the list in the agreement, the client confirms in writing that it matches, and the final invoice is due. Keep is optional but I always offer it: a monthly plan for fixes and small changes that begins at go-live. How to turn a one-off client into a monthly retainer covers that conversation.

A milestone only works if everyone agrees in advance what counts as done. Put three things in the statement of work. First, the checklist the build will be measured against, written in plain language as things the client can do or see. Second, the response window: the client has a set number of working days to accept or list the specific items that do not match the checklist. Third, the silence rule: if the window passes with no response, the milestone is treated as accepted and the invoice is due.

How to write a statement of work for an AI project has the full structure, and how many revisions to include in an AI project covers how many rounds of fixes fit inside each milestone. Without these, acceptance becomes an open-ended conversation and your payment becomes a hostage to it.

Give the client everything they need to judge the work, and hold back only what they need to run it without you. In practice that means: the preview link stays live throughout, but production access, the transfer of accounts and the source files are handed over after the Ship payment clears. State this in the agreement, in a sentence, before the project starts, so it reads as the process rather than as a threat.

Be fair about it. Do not hold back something the client already paid for, and do not hide a working build from them to force payment. The point is a sequence, not a standoff. How to hand off a Claude Code project covers the handover itself.

Put the schedule on the same page as the price, in the same plain language as the table above. When a client sees that money only moves when they have seen something working, the number feels safer, and the "what if you disappear" worry fades without you having to argue it. If they ask whether the fee can come down, the "can you do it cheaper" objection covers the answer, and the answer is almost never a discount: it is a smaller scope.