A milestone should represent an outcome.
A milestone is a defined piece of work with a proposed value. It gives both sides a checkpoint before moving to the next part of a project.
The best checkpoint is something that can be reviewed. “Work for a week” describes time spent; “deliver the agreed wireframes for review” describes an output. The right structure depends on the project and the people involved.
The current three-part split.
The draft builder uses a fixed 25% / 50% / 25% allocation. You can edit the deliverable names and the total project value; individual percentages are not editable in this version. Amounts are rounded to cents, with the final milestone taking the remainder so that the total stays consistent.
| Example milestone | Allocation | Example value |
|---|---|---|
| Direction & scope | 25% | 600 USDC |
| First delivery | 50% | 1,200 USDC |
| Final handover | 25% | 600 USDC |
| Total | 100% | 2,400 USDC |
Submission is not approval.
A contributor submitting work and a client approving it are different decisions. The proposed protocol would need to record that difference before linking approval to a payment release.
A review should refer back to the agreed scope and acceptance criteria. Additional requests should be identified as revisions within scope or as new work, rather than silently changing the milestone.
The proposed delivery sequence.
These delivery and approval actions are not available in the current workspace. The panel on the right is a live breakdown of your draft, not a record of submitted or completed work.
- Define the milestone and its acceptance criteria.
- Submit the agreed work and any supporting materials.
- Review it against the agreed criteria.
- Record approval or follow the agreed revision process.
- Release the assigned amount only under the eventual contract’s rules.
Give the final handover its own definition.
A final delivery may include editable source files, credentials or documentation as well as the visible result. Write those items into the scope so the final milestone does not become an open-ended list.
For longer projects, more milestones or a different allocation may be appropriate. Support for flexible allocations and additional stages is a design consideration, not a current feature.