Pay for Milestones You Can Check, Not for Weeks

On a fixed-scope build, tie every payment to an event you can check in a demo in under an hour, never to a date on the calendar and never to a percent-complete estimate. Keep the last slice of the price until the whole thing is accepted. That is the entire recommendation, and the rest of this article is why it holds and what it costs you.

The payment schedule is the part of a quote founders read least carefully, because the total is the number that got negotiated. It should be read most carefully. The total says what the work costs. The schedule says what you are actually buying at each point, and when your leverage runs out.

A schedule on dates is hourly billing with a fixed total

A quote that says “25% on signing, then 25% at the end of each month” has a fixed price and an hourly incentive. Each payment arrives because time passed. Whether anything you can use exists on the day it falls due is not a condition of paying it.

The US federal rulebook draws exactly this line, and it has been drawing it for a long time. It knows two main ways to pay a contractor before delivery. One pays against cost incurred: the customary progress payment rate is 80% of the contractor’s total costs for a large business and 85% for a small one.[1] The other pays against performance, and the rulebook calls that the preferred method wherever it is practical and the contractor agrees.[2]

Performance, in that sense, is something you can point at. The permitted bases are performance measured by objective, quantifiable methods, the accomplishment of defined events, or other quantifiable measures of results.[3] “Month two ended” is none of those.

Cost-based financing exists for good reasons in that world, mostly very long builds with heavy upfront spend. A software engagement measured in weeks is not that world. On a build that short, paying for elapsed weeks gives you all of the downside of hourly billing with none of the flexibility.

What makes a milestone payable

The same regulation sets three tests for an event that triggers a payment, and they transfer to a software contract almost word for word.[4]

1. It is an integral and necessary part of the work. Not a meeting, not a report about the work, not “kickoff complete”.
2. The buyer can readily verify it. Readily is the load-bearing word. If checking the milestone needs the vendor to explain it, it is not readily verifiable.
3. The amount is commensurate with the value of the event. A milestone that carries 40% of the price and delivers a login screen is financing, not payment for work.

Held against those tests, most milestones written in agency quotes fail the second one.

The left column is not dishonest. “Backend 50% done” may well be true. The problem is that it is true only on the vendor’s say-so, and a payment that rests on the vendor’s say-so is a payment on trust. The right column costs nothing extra to write, and it forces both sides to agree now what “done” will look like at each stop, which is the conversation that otherwise happens at the end under worse conditions.

The pattern that makes the right column work: a running system, a named environment, and a thing a user can do. If a milestone sentence is missing any of the three, rewrite it before signing.

Paying for a milestone is not accepting it

This is the clause buyers most often do not know they need. The federal performance-based payment clause says outright that approving a payment request does not constitute acceptance of the work.[5] Paying for milestone three does not mean you have agreed milestone three is correct.

That matters because milestones are checked on the happy path, in a demo, in an hour. Acceptance is checked against the full scope. If the contract treats each milestone payment as a sign-off, then every defect found later in something you already paid for becomes a negotiation about whether you accepted it. Write it the federal way: milestone payments are progress, and acceptance happens once, at the end, against the criteria you agreed at the start. We wrote separately about making those criteria something a build can fail, which is what turns final acceptance from an argument into a check.

The same clause handles the arithmetic cleanly. Payments made before delivery are liquidated against the delivery payment, deducted from it as a percentage or a set amount.[5] In plain terms, the milestones are advances on one fixed price, not separate purchases. A contract that reads as a sequence of separate purchases makes it much harder to say, at the end, that the whole thing does not yet work.

Keep a slice back until the end

The regulation caps total performance-based payments at 90% of the contract price.[4] The remaining 10% is paid on delivery, which means the contractor has a reason to finish the last, least interesting stretch of the work: the edge cases, the deploy runbook, the handover.

Ten percent is a federal number, not a law of nature, and it is a reasonable place to start. Below about that, the final payment is small enough that walking away from it is cheaper than finishing. Much above it, the vendor is carrying enough of the build on its own balance sheet that the price goes up to pay for that.

Here is how the pieces fit, on an example that is illustrative rather than a client engagement.

The first row deserves a note. It is a payment before any software exists, and that looks like it breaks the rule. It does not, as long as the thing being paid for is the scope document itself, delivered and usable. A scope with acceptance criteria is a deliverable you can take to another studio if you walk away. A payment for “starting” is not.

What this costs you, as the buyer

It is not free, and the costs land on you.

You have to show up to check. A milestone you can verify is only worth anything if you verify it, on time. If a staging demo sits unchecked for two weeks, the vendor’s cash sits with it, and a sensible vendor will ask for a clause that treats silence as approval after a set number of business days. Ask for that window to be written down, and read it as a promise you are making.

The price may go up. Paying on verified events means the vendor funds more of the work before being paid for it. Federal rules treat that as a real cost: financing is sized to what is actually needed for performance, with the contractor’s predelivery spending and working capital explicitly in the picture.[6] The same rules warn against a payment plan that leaves the contractor with an unreasonably low or negative stake of its own.[4] Both sides carry some of the build. Expect a quote that is back-loaded to be priced a little higher than one that is front-loaded, and decide whether the leverage is worth the difference. For most first builds it is.

A change request reshuffles the schedule. Milestones are slices of the scope. When the scope changes, the milestone it lands in changes with it, so a mid-project change is also a payment-schedule change. That is one more reason changes are priced before they are built.

The first payment is still trust. No schedule removes that. The most you can do is make the first payment buy something you keep.

Three checks for any payment schedule you are quoted

They take ten minutes and work on any vendor, including us:

1. Read each trigger and ask who confirms it. If the answer is the vendor, rewrite it as a thing you can do on a named environment.
2. Add up everything payable before final acceptance. If it is 100%, you have no leverage left at the point where most disputes happen.
3. Find the sentence that says what paying a milestone means. If it says, or implies, that payment is acceptance, strike it.

Our quotes come with a milestone plan for this reason: it is the part of a fixed price that tells you what you are buying each week, and it is where a fixed price either protects you or quietly stops doing so.