What makes a good milestone
- It ends in working software. A feature set you can click through, on a test environment, with realistic data.
- It has acceptance criteria. A short written list of what has to work for the milestone to count as done.
- It's small enough to limit your risk. If something goes wrong, you've lost weeks, not months.
- It's useful on its own. Ideally each milestone moves you closer to something real users can use.
Milestones to be wary of
| Weak milestone | Why it's risky | Better version |
|---|---|---|
| "Month 2 complete" | You pay for time passing, not results | "Orders can be created, approved and tracked" |
| "Design complete" | Designs can be approved and still not be buildable | Clickable prototype of the key flows, reviewed by you |
| "Backend 70% done" | Nothing you can test or verify | A working feature you can use end to end |
| "Final delivery" for most of the budget | Everything rides on the last step | Several milestones, each with its own payment |
The payment to start
Most agencies ask for a payment before work begins, so they can commit a team to your project. That's normal. What matters is that it's proportionate, covers a defined first milestone, and that you never pay for the whole project upfront.How acceptance should work
- The agency shows the milestone in a demo and gives you access to a test environment.
- You test it against the acceptance criteria within an agreed review window.
- You report anything that doesn't match the criteria.
- Those defects are fixed as part of the milestone.
- The milestone is accepted and invoiced.
When a milestone slips
Ask why, and what changes for the rest of the plan. A slip caused by a late decision on your side is different from one caused by an underestimate. Weekly demos make slips visible early, which is the main point of milestones. Our guide to why software quotes vary explains how estimates get built, and where they go wrong.When priorities change mid-project
Milestones make this easier, not harder. Instead of renegotiating the whole project, you re-plan the next milestone. Keep an eye on how small additions add up; the real cost of just one more feature shows why.After launch
Once the product is live, milestones usually give way to a monthly arrangement for maintenance and new features. Fixed price vs time and materials compares the options.A quick checklist before you agree payment terms
- Every milestone ends in working software you can test
- Each has written acceptance criteria
- There's a review window before a milestone counts as accepted
- Defects and changes are handled separately
- You keep everything delivered and paid for if the project stops
- These terms are in the contract, not just the proposal
How we structure payments
We split fixed-scope work into milestones, each tied to working software you can review, and you never pay for the whole project upfront. You can read more on our milestone payments page. The milestone breakdown and amounts for your project come with your written scope after the scoping call.FAQ
How many milestones should a software project have?
Enough that no single payment covers more than a few weeks of work. The exact number depends on the size of the project.Should I ever pay the whole project upfront?
No. Upfront payment for the whole project removes your main protection: being able to stop if the work isn't what you agreed.What if I'm not happy with a milestone?
Check it against the written acceptance criteria. If it doesn't meet them, report the gaps and they should be fixed before the milestone is accepted.Want to see how your project would split into milestones? Book a free scoping call.
