How to Structure Milestone Payments in a Software Project
Practice4 minInnovialabs editorial team
In short
A reliable setup is a modest prepayment to start, then a payment for each milestone after a specific deliverable is accepted against agreed criteria. That way neither the client nor the contractor carries the risk of the whole project at once.
The short answer
Split payment for a software project so that each payment matches a verifiable result. A typical setup:
- Prepayment — so the contractor reserves the team and starts work.
- Milestone payments — after acceptance of the design, individual modules, a test build.
- Final payment — after launch and a bug-fixing period.
The exact shares depend on project size, duration and trust between the parties, so they are agreed in the contract.
Three main payment models
| Model | How it works | Favors | Risk |
|---|---|---|---|
| Full prepayment | Paid before work starts | Contractor | Client risks the full amount |
| Milestone payments | Payment after each stage | Both sides | Spread across the project |
| Payment on delivery | Full amount after handover | Client | Contractor finances the project |
For projects longer than a couple of weeks, milestone payments are the most common choice: they reduce risk for both sides and keep the project moving.
A separate option is time & materials: the client pays for hours actually spent, for example monthly or per sprint. It fits when the scope is hard to define upfront. Then milestones become reporting periods, and control comes through reports and demos.
How to tie payments to deliverables
The main rule: a milestone should end with something you can see and check, not "50% of the work done".
Good milestone deliverables:
- approved mockups of key screens;
- a working feature in a test environment: sign-up, catalog, checkout;
- a test build of the app installed on your phone;
- migrated data verified on a sample;
- production launch.
For each milestone, the contract or its appendix should state:
- what is delivered — a list of results;
- acceptance criteria — what makes the result count as done;
- review period — how many days the client has to check it;
- what happens with remarks — deadlines for fixes;
- the payment amount.
Example milestone structure
An illustrative example for a mid-complexity web service:
| Milestone | Deliverable | Payment |
|---|---|---|
| Kickoff | Contract signed, specification agreed | Prepayment |
| Design | Key screen mockups approved | Payment 2 |
| Development, part 1 | Core features work in a test environment | Payment 3 |
| Development, part 2 | All features, integrations, admin panel | Payment 4 |
| Launch | Service is live, bug-fixing period completed | Final payment |
Choose the number of milestones to fit the project: stages that are too small create paperwork, stages that are too large bring the risk back.
Balancing risk
Client risks: paying and getting nothing, getting something other than expected.
Contractor risks: finishing work and waiting a long time for payment, endless unpaid revisions.
What helps both sides:
- A review deadline. If the client sends no remarks within the agreed period, the milestone is considered accepted. This protects the contractor from stalling.
- A limit on revisions. The number of revision rounds per stage is fixed; new wishes are handled as scope changes.
- A change request process. New tasks are estimated separately and added to the plan with separate payment.
- Handover of results. Source code and rights transfer as milestones are paid or after the final payment — state this explicitly.
- A warranty period. After launch, the contractor fixes bugs in the agreed functionality free of charge for an agreed period.
Common mistakes
- Milestones without acceptance criteria — it is unclear what you are paying for.
- A final payment that is too small — the contractor has no incentive to close loose ends.
- No review deadline — acceptance drags on for weeks.
- Fixes and new wishes mixed in one list.
- Verbal agreements on milestones that never make it into the contract.