Payment Milestones in Development Contracts: A Structure That Protects Both Sides

Payment milestones are the least seriously discussed clause in development contracts — and the one that most often ignites disputes. Clients fear "paying and getting nothing"; vendors fear "delivering and never seeing the final payment." Both fears are real, and both have their victims. This post lays out the payment structure we actually use: how to cut the milestones, how to set the ratios, and which clauses protect both sides at once.

The Principle: Money Tracks Deliverables

A healthy payment structure has one core logic: every payment corresponds to a visible, verifiable deliverable — not to the calendar. "Half on signing, half three months later" is bad design — for those three months both sides are exposed: the client doesn't know what the money bought, and the vendor doesn't know whether the work is even heading the right way.

For a mid-sized website or system project, the structure we typically use has three to four stages:

A few judgment calls on ratios: a deposit under twenty percent should make you wary of the vendor's financial health (they may be rolling projects to cover each other); a deposit over fifty percent puts too much risk on the client; and holding back roughly thirty percent as the final payment is the client's most concrete leverage over acceptance quality. For long-running or large projects, cut finer — split the midpoint into a payment per stage delivered, paired with a steady iteration rhythm, and both sides' risk smooths out.

Clauses That Protect the Client

• Deliverable definitions written into the contract: for each milestone, what gets delivered and by what standard it counts as done — in black and white. "Design completed" is too vague; "one design comp each for homepage and interior pages, including mobile versions" is a clause.
• Handover timing for source code and accounts: specify that within N days of final payment, the source code and full access to domain, hosting, and third-party services are handed over. Without this clause, you're paying rent, not buying.
• Termination clause: if the project stops midway, the results of completed stages — including code — belong to the client. This protects you from paying and walking away empty-handed.

Clauses That Protect the Vendor (Clients Should Understand These Too)

Why should clients understand the vendor's protective clauses? Because a contract that protects only one side guarantees the other side will claw the risk back some other way — usually through quality. Reasonable two-way clauses include: an acceptance window (no objections within N days of delivery counts as acceptance, preventing the final payment from being dragged out indefinitely); changes billed separately (out-of-scope requests go through the change process and get quoted, preventing "just add one thing" from eating the margin); and a client-delay clause (late assets or feedback push the schedule accordingly). A vendor willing to put all this on the table is usually a vendor who works transparently. The ones who dodge talking about money are the ones to fear later.

A good payment structure isn't about one side defending against the other — it's about squaring accounts at every milestone: the client's money always bought something, and the vendor's work always got paid.

Before You Sign, Use This Post as a Checklist

Next time you're handed a quote and a contract, check it against this post: does every milestone map to a deliverable? Are acceptance criteria written down? Is the source-code handover timing explicit? Are the protections two-way? If you have a contract in hand you'd like a second opinion on, or want to hear how your project should be milestoned, book a free 30-minute consultation — putting contract terms on the table is what we do best.