Charging a 50% upfront payment and the rest at the end works perfectly for projects that last a couple of weeks. But what happens when the project takes three, four, or six months to complete?
If you depend on a single final milestone to collect half your money, any delay caused by the client (like taking weeks to deliver the copy for a website) will leave you without liquidity. And if the relationship breaks down in month four, you will have single-handedly financed most of the project.
For long projects, the safest and fairest model for both parties is the partial payment (or milestone payment) scheme.
What is a milestone payment?
Instead of tying payment only to the start and the end, you divide the total project cost into fractions that are released as specific phases of the work are completed.
The principle governing the whole scheme fits in one sentence: at any point in the project, the work delivered and the money collected should be roughly in step. If 70% of the work is done and only 30% is paid, the risk is yours. If it is the other way around, the risk is the client’s. Milestones exist so neither party finances the other.
This guarantees you are always collecting for the value delivered to date, and it reassures the client because they pay as they see tangible results, not everything at once.
Common partial payment structures
The breakdown depends on the nature of your service, but here are the three most effective models.
| Model | Ideal for | Typical scheme |
|---|---|---|
| Thirds | 1-2 month projects | 33 / 33 / 34 |
| By deliverables | Development, branding, architecture | 20-30% initial + phases |
| By dates (retainer) | Consulting, variable scope | Monthly invoicing |
1. The thirds model (33 / 33 / 34)
Ideal for medium projects (1 to 2 months).
- 33% deposit: To schedule and begin the research or strategy phase.
- 33% at the midpoint: For example, upon approval of the first sketches, wireframes, or the first draft of the copy.
- 34% final: Upon delivery of the final project and before transferring source files or passwords.
2. The deliverables model (e.g., web development)
For software development, corporate branding, or architecture projects, where phases are clearly marked.
- 20% Deposit
- 25% UI design approval: The client approves the visual part.
- 30% Development completed (staging): The client can see the project working, but it is not public yet.
- 25% Launch: The project goes to production.
In web projects the 30/30/30/10 variant is also common: 30% on signing, 30% on design approval, 30% with development on staging, and the final 10% at launch. The logic is the same; what matters is keeping the last payment small, because it is the one that tends to drag the most.
3. The date-based model (retainer)
If the scope is variable or it is pure consulting, tie payments to the calendar, not to deliverables.
- Day 1: Monthly advance.
- Day 30: Invoice for the first month’s work.
- Day 60: Invoice for the second month’s work.
How to define a good milestone
Not every division of the project works as a payment milestone. A useful milestone meets three conditions:
- It is objective. “Delivery of the first draft” can be verified; “significant project progress” cannot. If the milestone allows interpretation, it will allow argument.
- It depends on you. The milestone is met by your delivery, not by an action of the client. More on this below, because it is the scheme’s most expensive mistake.
- It has visible value for the client. Paying feels different when what was just received can be seen or used. “Approved design” or “browsable website on staging” are milestones nobody disputes; “internal environment setup” is real but invisible work, and it is better bundled with something showable.
Golden rules for milestone billing
For this system to work, you must lock it in from the drafting of your freelance contract.
1. Work stops if there is no payment
Include a clause stating: “The start of Phase 3 is subject to payment of the amount corresponding to Phase 2.” If the client falls behind on a milestone, you stop production. Never move to the next phase dragging debt.
The quiet advantage of this scheme is that pausing is not a confrontation: it is a normal contractual step. You do not have to get angry or make threats; the next phase simply does not start until the previous one is settled. Milestones turn your only real leverage (your future work) into a mechanism both parties agreed on.
Payment problems also surface early, while you still have room to maneuver, instead of at the end, with all the work delivered and unpaid.
2. Tie the milestone to YOUR delivery, not THEIR review
This is the most costly mistake: conditioning payment on the client’s “final approval.” If the client goes on vacation and does not approve your work, you do not get paid.
The condition must be objective: “30% upon delivery of the first draft.” The milestone is met when you make the delivery, not when the client reviews it. (Revisions are part of the work already paid for in that phase.)
A reasonable middle ground for clients who insist on approving before paying: set a review window with automatic approval. “The client has 5 business days for observations; after that period with no response, the delivery is considered approved and payment becomes due.” The client keeps their right to review, and you stop depending on their inbox.
3. Invoice each milestone immediately
A completed milestone that is not invoiced the same day turns into fuzzy money. Send the invoice together with the delivery (“attached is the Phase 2 deliverable and the corresponding invoice”), with a clear due date. Collection loses all its awkwardness when it is a routine administrative act rather than a special conversation.
What if the client requests changes midway?
In long projects, the scope never survives intact. The client will see progress and want to adjust things: that is normal, even a good sign. What cannot happen is changes sneaking inside milestones that were already budgeted.
The correct mechanics: small changes within scope are absorbed by the planned revisions; changes that alter the scope get quoted as an add-on, with their own price and, if large, their own payment milestone. The approved quote is your reference for telling one from the other.
If the client asks to freeze the project for a while (“we’ll pick it up in two months”), invoice the work done to date before pausing. A frozen project with an outstanding balance has an uncomfortable probability of never thawing.
When are milestones NOT worth it?
The milestone scheme is a tool, not a religion. There are cases where it adds more bureaucracy than protection:
- Short projects. For one or two weeks of work, the classic 50% deposit and 50% on delivery is simpler and sufficient. Splitting a thousand dollars into four invoices is punishing yourself.
- Low-priced packaged services. If you sell a standardized service (a session, a diagnosis, a single piece), charge the full amount upfront and be done.
- Established retainer relationships. With a stable monthly client, the milestone is the calendar: a fixed invoice every month. Adding per-deliverable milestones within the month is usually noise.
The deciding question is always the same: how much unpaid work would you be accumulating at the project’s worst moment? If the answer is “little,” you do not need milestones. If it is “two months of my life,” you need them urgently.
How to keep track without losing your mind
Mentally tracking that “Client A” paid milestone 1 but has owed milestone 2 for 5 days, while “Client B” just paid milestone 3, is unsustainable. With two or three simultaneous projects, the crossed balances become a job in themselves.
Use Pagatu’s payments module to record every partial payment from your clients. At a glance you can see the project’s total balance, how much has been paid to date, and what amount is pending, letting you send precise reminders without reviewing your bank statements every week.
One last practical note: communicate each completed milestone with a short message summarizing what was delivered and what comes next. The invoice arrives better accompanied by context (“Phase 2 delivered: approved design, next stop staging”) than alone in an inbox.
A well-structured long project feels different from the first month: you collect at a steady rhythm, the client pays for results they can see, and neither of you reaches the end with a giant invoice and frayed nerves.