How should milestone payments be structured for a software project?
Tie each payment to an inspectable and transferable result instead of copying a 30:30:30:10 schedule. Every milestone should state the triggering evidence, review period, remediation and retest process, and what happens if either party exits. The percentages depend on cash flow, irreversible purchases, duration, and allocated risk; there is no universal minimum deposit or retention.
A mobilization payment can legitimately reserve a team and fund non-recoverable startup work. Terms such as “design approved,” “60% developed,” or “stable after launch” are still subjective unless the contract defines observable evidence.
When defining budget, scope, and cost assumptions, also compare Should a software platform plan every feature for the next five years? and Can a project launch its core in phases when the budget tightens halfway through?; the linked guidance adds context that should be considered in the same decision.
| Milestone | Sufficient trigger | Weak wording | If it does not pass |
|---|---|---|---|
| Mobilization | Effective contract, assigned team, confirmed plan and account list | “Project started” | Agreed refund or schedule adjustment if mobilization fails |
| Discovery and solution | Role flows, prototype, interface samples, risks, first-release scope | “Requirements discussed” | Named revision rounds or approved paid change |
| Runnable increment | Accessible environment and agreed stories/tests passing | “Development 60% complete” | Defect severity, correction deadline, and retest |
| Production release | Client-account deployment, migration reconciliation, monitoring, rollback, training | “Submitted to the store” | Separate platform rejection causes and responsibilities |
| Final acceptance and handover | Signed result, source, documents, credentials, open-item register | “One month without any issue” | Deemed-acceptance conditions and retention for named items |
For a short, defined project, mobilization, one runnable midpoint, and final handover may be enough. When a risky integration or migration could invalidate the plan, contract discovery or a technical proof separately and let the client stop before major construction. A continuously evolving product can use a fixed periodic budget with review and reprioritization. Hardware and licence purchases should be separated from engineering milestones so ownership and original cost remain visible.
Payment does not replace acceptance, and final retention is not the only quality protection. Define defect severity, response and correction, warranty boundary, liability, and intellectual-property delivery. Set a review window and deemed-confirmation rule when the client does not respond. If delivery misses the baseline, specify remediation, retest, payment pause, and delivery of usable code and data after termination.
Changes should state their impact on scope, price, schedule, and acceptance before an authorized person approves them. An emergency oral instruction can follow an agreed fast path but still needs a written record. Client-owned cloud, messaging, AI, and store accounts and their direct charges should remain separate from development milestones, preventing a supplier dispute from locking production assets.
Before each payment, one evidence package should show the committed result, environment and version, acceptance cases and outcome, known defects, code and document location, next dependencies, and approved changes. The client does not need to inspect every line of code but must be able to reproduce the critical task; the supplier is not obliged to perform unlimited rework against an undefined feeling.
Wavesteam designs milestones from project risk rather than a fixed ratio. Each stage leaves a runnable version, test record, and scope variance that the client can inspect and take over. If early evidence disproves the business or technical assumption, we recommend reducing or stopping the next investment instead of using the original payment calendar to force a longer roadmap.