What is a development payment milestone?

A milestone is a contract point where a defined deliverable is accepted and an invoice falls due. It splits a project into verifiable stages — discovery, build, UAT, launch — instead of billing by calendar month. Each milestone needs written acceptance criteria, so "done" is a test rather than an opinion. The contract should name the invoice trigger and the payment window.

How large should the upfront deposit be?

The deposit covers discovery, environment setup and the first weeks of work before any milestone is accepted. Common practice is roughly a quarter to half of the contract value, weighted toward the start. Fund it from the client's own budget, never from a promise of later work, and check the exact terms in the signed contract.

Should milestone payments be tied to dates or deliverables?

Deliverables. Dates depend on feedback turnaround and access, which the client controls. Tie each invoice to an accepted artefact — a deployed staging build, a signed-off design, a passing test suite — and keep dates as targets with a stated review window. If a milestone stalls on client feedback, the schedule moves, not the scope.

What acceptance criteria should each milestone carry?

Write them as testable statements: "the checkout completes a test card payment on staging", not "checkout works". Name the environment, the test data and who signs off. State what is explicitly out of scope for that milestone so the next one does not absorb it. Vague criteria are the main cause of milestone disputes.

How do you verify a milestone before releasing payment?

Test on the environment named in the contract, using the client's own data or a realistic copy. Walk the acceptance criteria one by one, log defects with steps to reproduce, and confirm the build tag or commit hash under review. A written sign-off or signed acceptance sheet releases the invoice; a verbal "looks good" does not.

What happens when a milestone is delivered late?

Usually nothing automatic — the schedule slips, but the fee does not change unless the contract names a service credit. Late delivery is often a symptom: unclear scope, slow feedback, or a dependency the client owns. Diagnose the cause first, then agree a revised date in writing. Read the delay clause before withholding anything.

How should change requests between milestones be handled?

As a separate written change order with its own estimate, agreed before the work starts. A change touching an unaccepted milestone can fold into that milestone's acceptance criteria; one touching accepted work becomes a new line item. Without this discipline, small requests erode the budget and the final milestone never closes cleanly.

What should be withheld until the final payment clears?

Not the working system — that invites disputes. Withhold the transferables: production deployment, repository ownership handover, credentials, DNS and account transfers, and the final documentation pack. Put this in the contract. On payment the client receives everything, and the underlying accounts were already registered in their name.

What is retention and does it apply to software projects?

Retention is a percentage held back after practical completion for a defect period, common in construction contracts. Software agreements often mimic it as a warranty window where genuine defects are fixed at no charge. Distinguish defects from new work. Agree the window length and the definition of a defect in writing before the final invoice.

What if the client refuses to pay the final invoice?

First check whether the acceptance criteria were actually met — most disputes start there. Then follow the contract's notice and cure steps before anything else. Alternatives to litigation include staged handover, escrow of the disputed amount, or mediation. Keep milestone sign-offs and delivery records, because they decide these cases.

Development Payment Milestones That Protect Both Sides

The deposit, the milestones and the final payment

Development payment milestones split a build into funded stages: a deposit, one or more payments tied to named deliverables, and a final payment on acceptance. Each instalment is released only when a checkable piece of work is signed off, so neither side carries the whole project's risk at once.

Key Takeaways

Milestones turn a vague promise into a short list of things you can log into, test and sign off.
Every milestone needs three things in writing: a trigger, evidence, and an acceptance window.
The deposit funds mobilisation. It is not a refundable security deposit, and it rarely comes back if you walk away.
Holdback and warranty clauses decide whether the final payment lands at go-live or weeks afterwards.
Source code, cloud accounts, domains and credentials should transfer as an explicit milestone deliverable, in your name.
Short, tightly specified jobs usually run better on a deposit plus one final payment than on four milestones.

A typical five-stage development payment milestone flow, from the mobilisation deposit through design sign-off and a testable staging build to acceptance and handover.

What are development payment milestones?

Development payment milestones tie each instalment to a delivered, checkable piece of work. Instead of paying for time, you pay for outcomes: a signed-off design, a working staging build, a passed acceptance test. The contract names what must exist before an invoice is valid, and who signs it off.

That last part matters more than people expect. "Signed off by the client" sounds fine until the client's marketing lead, IT manager and finance director all assume someone else is responsible. Name one approver and one backup.

Why does milestone billing matter on a real project?

Milestones matter because they cap exposure on both sides. You never fund the whole build before you have seen anything run, and the vendor never finances months of work on a promise. The schedule also forces a written definition of done at each stage, which is the same artefact you will use later to judge quality.

There is a quieter benefit. When payments land every few weeks, both sides keep talking. Projects that go silent for a quarter are almost always projects with one large payment sitting at the end.

When do you actually need milestones, and when is a simpler schedule fine?

Milestones earn their admin overhead on anything longer than a few weeks or larger than a single deliverable. Short, well-specified jobs — a WordPress theme, a landing page, one integration — often run fine on a deposit and a single final payment. If the scope is genuinely unclear, milestones will not save you; a paid discovery phase will.

We have watched a four-milestone schedule slow down a two-week job that everyone already understood. The paperwork took longer than the build. Choosing between structures is its own decision, and we compare the trade-offs in fixed price versus hourly development.

How does the mechanism work?

The mechanism has three parts. A trigger names the event that makes an invoice due. Evidence is the artefact that proves the event happened — a staging URL, a test report, a signed checklist. Acceptance is the window in which you may reject the work, and what happens if you stay silent.

The trigger

Write triggers as events, not dates. "Staging environment available at the agreed URL and passing the acceptance checklist" beats "end of month three". Dates slip; deliverables are what you are buying. If a vendor insists on date-based invoicing, that is time and materials wearing a fixed-price coat.

The evidence

Decide before kickoff what counts as proof. A screen recording of a feature working on someone's laptop is not evidence. A staging URL you can log into, break, and reload is. For infrastructure work, the evidence might be a monitoring dashboard or a restore test you watched run.

The acceptance window

Give yourself a fixed number of working days to test, then define deemed acceptance: if you raise no written defects in that window, the milestone is accepted and the invoice is payable. Without this clause, a busy client can stall a project indefinitely simply by not replying.

Milestone 3 is accepted when the staging environment at the agreed URL passes the acceptance checklist in Appendix B, or automatically fourteen working days after delivery if no written defects are raised.

How do you set up a payment milestone schedule?

Set up the schedule before the contract is signed, working backwards from go-live. Each milestone should be independently verifiable, roughly matched to effort already spent, and described in the same words your developer uses on the sprint board. Ambiguity here becomes an argument later.

Write the definition of done first. Describe each deliverable in one sentence a non-technical colleague could verify.
Group the work into three to five milestones. Fewer than three and you are back to financing the whole build; more than five and invoicing becomes a part-time job.
Match payment to effort already spent. A milestone that pays well after the work is done turns your vendor into your bank, and that shows up in the price.
Fix the deposit at mobilisation cost. It covers discovery, environment setup and the first build sprint — real work you have already received.
Add the evidence requirement to each line. Staging URL, test report, migration log, signed checklist.
Agree the acceptance window and the change-request process. Both belong in the same document as the payment schedule.
Decide the holdback and handover sequence. State when source, credentials and accounts move, and what releases the final payment.

If the project is large enough to be split by phase rather than by feature, a phased structure may suit better — that approach is covered in phased web development.

Which clauses actually decide who carries the risk?

Four clauses decide most disputes: the acceptance window and what silence means, the change-request process, the holdback or warranty period, and when intellectual property and credentials transfer. Read them together. A generous acceptance window with no deemed-acceptance rule lets a project stall with your invoice unpaid.

The change-request clause deserves particular attention. Without one, every small addition becomes a negotiation at the next milestone, and the vendor either absorbs it or the relationship sours. With one, new scope gets quoted, approved in writing, and slotted in.

How do you verify a milestone is genuinely complete?

Verify against a running environment, not a demo. Ask for a staging URL you can log into, run the acceptance checklist yourself, and check the boring things — error states, mobile layout, behaviour with an empty database. A screen share proves a feature exists on one machine; a staging environment you can break proves it works.

For handover milestones, verify access rather than claims. Confirm you can deploy from your own repository, that DNS is in your registrar account, and that no production credential lives only in someone's password manager.

What are the common failure modes, and how do you debug them?

Most milestone disputes trace back to a vague definition of done, not bad faith. When a payment stalls, check in this order: the contract wording, the acceptance evidence, the change log, then the communication trail. Each step rules out a cause, and you usually find the real problem by step three.

The milestone never quite finishes. Usually the definition of done was a direction, not a deliverable. Rewrite it, both parties sign, restart the clock.
"That's a change request." If the original scope did not mention it, the vendor is technically right. This is a scoping failure, and the fix is a written change process, not a standoff.
Silent non-acceptance. The client is busy, nobody signs, the invoice ages. Deemed acceptance fixes this permanently.
The final payment never lands. Often the holdback is tied to something the vendor does not control, such as a third-party integration going live. Tie it to a date or to your own acceptance.

How each payment type on a development project maps to its trigger and the evidence that makes the invoice valid.

What does milestone billing cost to run?

Milestone billing costs admin time, not licence fees. Someone has to write acceptance criteria, chase sign-off and keep a change log. Expect a short overhead per milestone on both sides. The payoff is fewer end-of-project arguments and a paper trail you can point to if a dispute ever escalates.

The hidden cost is rework. A milestone that exposes a misunderstanding early is cheap; the same misunderstanding found at go-live is expensive. For a sense of what belongs in the underlying estimate, see our breakdown of a web development quote.

What are the security and ownership considerations?

Treat credentials as a milestone deliverable in their own right. Source code, cloud accounts, domain registration, DNS and email should sit in your name from day one, with the vendor working as a collaborator rather than an owner. If the build stops, you should still be able to deploy what you have paid for.

Two practical checks: confirm you are the billing owner on the cloud account, and make sure at least two people on your side can restore from backup without the vendor's help. If a supplier disappears, those two facts decide whether you have a bad week or a bad year. Our frequently asked questions cover how we handle ownership on client projects.

Which payment structure fits which project?

Match the structure to how much uncertainty you can tolerate. Fixed-scope work suits milestone billing; exploratory work suits time and materials with a cap; ongoing maintenance suits a monthly retainer. The wrong structure creates more friction than the wrong vendor often does.

Structure	How it works	Risk sits with	Best fit
Deposit plus milestones plus final	Payments released as named deliverables pass acceptance	Shared, stage by stage	Defined builds running several weeks or more
Deposit plus single final payment	One payment at kickoff, one on delivery	Vendor until delivery, then you	Short, tightly specified jobs
Time and materials with a cap	You pay for hours worked up to an agreed ceiling	You	Discovery and genuinely uncertain scope
Monthly retainer	Recurring fee for an agreed scope of support	You, month to month	Maintenance, hosting and support work

A milestone timeline for a typical build, showing when the deposit, staging payment, final invoice and warranty holdback each fall due.

A realistic scenario

A Kathmandu retailer asked us to take over a half-built inventory portal. The original contract had two payments: a large deposit and a balance on delivery. Ten months in, the balance was still unpaid, the vendor had stopped responding, and nobody could say what "delivery" meant. The client could not even deploy what already existed, because the cloud account and the repository both sat in the vendor's name.

We rebuilt the schedule before writing any code. A short paid discovery fixed the scope on paper. Then four milestones: staging environment reachable and seeded with test data; product and stock modules working end to end; the migration rehearsed on a copy of the live database; go-live with credentials transferred. Each had one named approver on the client side and a two-week acceptance window.

Two of the four milestones surfaced disagreements — one about tax rounding, one about who owned the barcode data import. Both got resolved in a fortnight because the evidence was on a staging server and the acceptance window had teeth. The final payment landed on the go-live date, and the holdback released a month later. None of that was about trust. It was about writing down what "done" meant.

In short: development payment milestones are a risk-sharing tool, not a billing formality. Write the trigger, the evidence and the acceptance window for each one, keep accounts and credentials in your own name, and tie the final payment to something you control.

People also search for

Teams planning a build usually search these questions alongside payment milestones. Each guide below covers one part of the commercial side of a software project, from how a quote is itemised to whether fixed price or hourly billing suits your scope.

If you would rather have the schedule reviewed before anyone signs it, our team can help you write the milestones, acceptance criteria and handover clauses for your project — and you keep the document whether or not you work with us. Take a look at the services we provide, or get in touch and describe what you are building.

Frequently asked questions

A milestone is a contract point where a defined deliverable is accepted and an invoice falls due. It splits a project into verifiable stages — discovery, build, UAT, launch — instead of billing by calendar month. Each milestone needs written acceptance criteria, so "done" is a test rather than an opinion. The contract should name the invoice trigger and the payment window.
The deposit covers discovery, environment setup and the first weeks of work before any milestone is accepted. Common practice is roughly a quarter to half of the contract value, weighted toward the start. Fund it from the client's own budget, never from a promise of later work, and check the exact terms in the signed contract.
Deliverables. Dates depend on feedback turnaround and access, which the client controls. Tie each invoice to an accepted artefact — a deployed staging build, a signed-off design, a passing test suite — and keep dates as targets with a stated review window. If a milestone stalls on client feedback, the schedule moves, not the scope.
Write them as testable statements: "the checkout completes a test card payment on staging", not "checkout works". Name the environment, the test data and who signs off. State what is explicitly out of scope for that milestone so the next one does not absorb it. Vague criteria are the main cause of milestone disputes.
Test on the environment named in the contract, using the client's own data or a realistic copy. Walk the acceptance criteria one by one, log defects with steps to reproduce, and confirm the build tag or commit hash under review. A written sign-off or signed acceptance sheet releases the invoice; a verbal "looks good" does not.
Usually nothing automatic — the schedule slips, but the fee does not change unless the contract names a service credit. Late delivery is often a symptom: unclear scope, slow feedback, or a dependency the client owns. Diagnose the cause first, then agree a revised date in writing. Read the delay clause before withholding anything.
As a separate written change order with its own estimate, agreed before the work starts. A change touching an unaccepted milestone can fold into that milestone's acceptance criteria; one touching accepted work becomes a new line item. Without this discipline, small requests erode the budget and the final milestone never closes cleanly.
Not the working system — that invites disputes. Withhold the transferables: production deployment, repository ownership handover, credentials, DNS and account transfers, and the final documentation pack. Put this in the contract. On payment the client receives everything, and the underlying accounts were already registered in their name.
Retention is a percentage held back after practical completion for a defect period, common in construction contracts. Software agreements often mimic it as a warranty window where genuine defects are fixed at no charge. Distinguish defects from new work. Agree the window length and the definition of a defect in writing before the final invoice.
First check whether the acceptance criteria were actually met — most disputes start there. Then follow the contract's notice and cure steps before anything else. Alternatives to litigation include staged handover, escrow of the disputed amount, or mediation. Keep milestone sign-offs and delivery records, because they decide these cases.