Money structure is project structure. The way payments are scheduled shapes who carries risk, how fast problems surface, and whether the end of the project is friendly or a standoff. Here is what is normal and what I would sign as both a developer and a client.
The three standard schedules
50/50. Half to start, half at launch. Fine for small, short projects (under about $5,000) where the gap between deposit and delivery is a few weeks.
33/33/33. Deposit, midpoint (usually design approval), and launch. Common up to around $15,000. Simple, and the midpoint lands when there is something real to review.
Milestone-based. The project is split into stages, each scoped, priced, and paid on delivery: discovery, design, build, launch. This is what I use for anything over a few thousand, and it is the friendliest to both sides. Here is why.
Why milestones protect YOU (not just the developer)
The client fear is paying money and getting nothing. Milestones answer that directly:
- Every payment is exchanged for something you can see and click
- If things go wrong after milestone two, your exposure is bounded; you have paid for two deliverables and you own them
- Problems surface at stage boundaries, when they are cheap to fix, instead of at launch, when they are not
Compare that to 50/50 on a 4-month project: you pay half before anything exists, then carry the whole second half as a single bet on a stranger's follow-through.
Why the deposit is non-negotiable
From the developer side, the mirror fear is working a month unpaid. The deposit is not distrust; it is the thing that makes everything after it trust-based. It also covers the real, unrecoverable hours: discovery, scope writing, design exploration.
A developer with zero deposit is either desperate or planning to bill you differently later. Both are worth knowing before you sign.
What a healthy payment section looks like
Plain language beats clever legalese. Something like:
- 30% deposit to book the start date ($3,300)
- 30% on design approval ($3,300)
- 40% on launch, due within 7 days ($4,400)
- Changes outside the written scope are quoted and approved separately before work begins
- Late payments pause work; the timeline shifts by the pause
Note what is in there: a pause clause. Work stopping when payment stops is not punishment, it is how the developer avoids financing your project out of pocket. You want that written down, because unwritten versions turn into resentment and rushed handovers.
Late payments and pauses, from both chairs
If YOU are the one waiting on a fix: pause clauses work in your favor too. They create a paper trail. If the developer pauses work on a paid-up project without cause, the schedule slip is now documented, which matters if things ever get formal.
Deposits and refunds
The deposit buys scheduled work and reserved time. If you cancel before design starts, some of it may be refundable; after design approval, generally not, because the deliverable exists. Ask what the refund position is at each milestone and get the answer in the contract. One sentence now prevents the worst conversation in freelancing later.
Red flags in either direction
- Developer demands 100% upfront
- Client wants net-90 on a $6,000 project (that is free financing, not a partnership)
- No payment schedule at all, just "we'll figure it out"
- Final payment "whenever I'm satisfied," with satisfaction undefined
The version I actually use
Deposit to start, payment at each milestone delivery, final balance due at launch with a 7-day window, and 14 days of free tweaks after launch so neither of us is incented to rush the ending. Clean starts, clean endings, and nobody is holding the other hostage at the finish line.
If you are about to sign something and the payment section feels off, send it over. I will tell you how I would restructure it and why.