How to Set Project Milestones With Your Agency

Who This Guide Is For

Business owners and project sponsors working with an external development agency who want to structure the engagement around clear milestones that provide visibility into progress and tie payments to deliverables.

Before You Start

• Milestones are not tasks. A milestone is a meaningful checkpoint: a point where something tangible is delivered or demonstrated. “Homepage designed” is a milestone. “Attended design meeting” is a task.
• Milestones require agreement. Both you and the agency need to agree on what each milestone includes and how completion will be verified.
• Fewer is better than more. Five to eight milestones for a typical project. Too many milestones create administrative overhead without adding clarity.

Step 1: Define What “Done” Means

For each milestone, define specific, verifiable completion criteria:

• Bad: “Design complete”
• Good: “Homepage, services page, and contact page designs approved in Figma. Responsive layouts for desktop and mobile included. Client has signed off on all three.”

Clear completion criteria prevent disagreements about whether a milestone has been met. If you cannot describe what “done” looks like, the milestone is too vague.

Step 2: Structure Milestones Around Deliverables

Organise milestones around what the agency delivers, not how they work internally. A typical structure for a custom software project:

1. Discovery complete. Requirements documented, workflows mapped, technical approach agreed. Deliverable: specification document.
2. Design complete. UI/UX designs for all key screens approved. Deliverable: design files.
3. Core functionality built. The main features work in a staging environment. Deliverable: access to staging with working core features.
4. Integrations complete. All third-party connections are working. Deliverable: demonstrated integrations with real data.
5. User acceptance testing passed. Your team has tested the system and confirmed it meets requirements. Deliverable: signed UAT report.
6. Launch. System deployed to production. Deliverable: live system with documentation and handover.

Step 3: Tie Payments to Milestones

Milestone-based payments protect both sides:

• For you: You only pay for work that has been demonstrably completed.
• For the agency: They get paid as they deliver, maintaining cash flow.

A common structure: 20% on project kickoff, then equal portions at each subsequent milestone. Alternatively, weight payments toward later milestones where the deliverables are more substantial.

Include a retention clause: hold back 10-15% of the total until a post-launch snagging period (typically 30 days) has passed without critical issues.

Step 4: Establish Review Points

At each milestone, schedule a formal review:

• Demo. The agency demonstrates what has been built against the milestone criteria.
• Review period. You have a defined time (typically three to five business days) to review and provide feedback.
• Acceptance or revision. You either accept the milestone or provide a specific list of items that need to change for acceptance.

Document the review process in the project agreement. This prevents ambiguity about how milestones are accepted and what happens when they are not.

Step 5: Plan for Changes

Requirements change during projects. Define how changes affect milestones:

• Minor changes. Small adjustments that do not affect the milestone scope or timeline are absorbed.
• Significant changes. Changes that add scope, require new milestones, or affect the timeline are documented as change requests with cost and timeline implications.
• Milestone changes. If a milestone needs to be redefined due to changed requirements, both parties agree on the new definition and any cost adjustment.

Having this process agreed upfront prevents disputes when changes (inevitably) arise.

Common Mistakes

• Setting milestones too far apart. If the first deliverable is three months away, you have no visibility into progress for three months. Space milestones two to four weeks apart.
• Making milestones too vague. “Backend development complete” means different things to different people. Define exactly what is included.
• Not reviewing milestones on time. If you take three weeks to review a milestone, you delay the entire project. Commit to your review timelines.
• Treating milestones as guarantees. Milestones are checkpoints, not contracts for perfection. Some refinement between milestones is normal.
• Front-loading payments. Do not pay 50% upfront. A reasonable upfront payment is 10-20%, with the rest tied to deliverables.

What Good Looks Like

Well-structured milestones provide regular visibility into progress (every two to four weeks), clear criteria for completion, payments that align with delivered value, and a process for handling changes. Both you and the agency know exactly where the project stands at any given time.

Next Steps

For guidance on choosing the right agency, see How to Choose a Software Development Partner. For the broader project planning process, How to Plan a Custom Software Project provides the full framework. If you are still at the brief-writing stage, How to Write a Brief for a Software Agency covers what to prepare before you approach agencies. To understand how we structure project delivery, see Custom Software Development.