Website Deposits and Milestone Payments: What to Agree Before Paying

Money is where web design projects get complicated, and it's usually not the amount — it's the schedule. Who pays what, when, and what happens if the work doesn't arrive. Almost every web design horror story involves a payment structure that put all the leverage on one side of the table.

The good news: payment structure is entirely negotiable, and the right questions take about ten minutes to ask. Here's how the common structures work, what each one protects, and what to agree before any money moves.

Why the payment schedule matters more than the price

A $4,000 website paid in three milestone chunks is a $4,000 website. A $4,000 website paid entirely upfront is a $4,000 bet. Same number, entirely different risk.

The schedule determines what happens when something goes wrong — and in any project that runs months, something goes wrong. The schedule decides whether a mid-project problem is a conversation between two parties who each still have something the other wants, or a demand from a client whose only remaining leverage is small-claims court.

That's why the payment terms deserve the same scrutiny as the design.

The structures, compared

The classic 50/50. Half at signing, half at completion. It's the most common arrangement in the industry, and it has an obvious weakness: by the end of week one, the designer has been paid most of the money. Every remaining incentive — revisions, responsiveness, the final push to launch — is now discretionary. Most designers behave anyway, because reputation is their business. But the structure itself offers you nothing if they don't.

Milestone payments. The deposit, then payments tied to defined stages: design approved, development complete, launch delivered. Usually three or four payments. At every point in the project, the designer has been paid roughly for the work delivered, and there's always a next payment on the table to keep things moving. This is the structure that best protects both sides, and it's the one worth asking for.

Pay-per-round or ongoing retainers. Less common for full builds, normal for ongoing work. Fine for maintenance and content work where the relationship is continuous; risky for a defined project, because there's no completion event to tie the final payment to.

Everything upfront. Occasionally proposed by small studios with cash-flow pressure. There is no version of this that protects you. If a designer asks for 100% of the project cost before starting, the honest move is to decline and propose milestones — and to notice that they asked.

What a deposit is actually for

To be fair to the other side of the table: deposits exist for a reason, and it isn't greed.

A designer who starts your project turns away other work for the weeks your build occupies. If a client vanishes after the design phase — and clients do vanish — the deposit is the only thing that makes the weeks not a total loss. Deposits also filter out the clients who want "just a quick site, will pay you after it makes money," a category of inquiry every working designer has learned to recognize.

So the question isn't whether to pay a deposit. It's whether the deposit is sized to the risk. A third to half of the total is the normal range for a project with milestone payments behind it. The number to be wary of isn't the size of the deposit — it's the size of the final payment, the one that's supposed to be your leverage at the finish line and instead becomes a rounding error.

What to agree before money moves

Whatever structure you land on, put these four things in writing first:

What each payment triggers. Not "50% at start" but "final payment due on delivery of the launched site, with all credentials transferred." Every payment should be tied to a countable event. A payment tied to nothing is a gift.

What happens if the project stalls. Projects stall for both reasons: designers get buried, and clients go quiet on feedback. Decide in advance what happens to money already paid if either side walks. If there's no termination clause in the agreement, the contract assumes nothing will ever go wrong — read the contract red flags piece before signing that one.

Who controls the accounts the money built. The domain, the hosting, the code repository. If your payments are building an asset that lives on the designer's accounts, you're financing something you don't own. The full ownership checklist lives in who really owns your website.

What a change costs, and when. Scope changes are normal — projects reveal things as they take shape. The structure to insist on is simple: changes are quoted before the changed work starts. That keeps a fixed price fixed and keeps surprise invoices structurally impossible.

If things have already gone wrong

If you're reading this after paying a deposit to a designer who has gone quiet: don't send angry messages in five channels at once. Send one written email — email, because it creates a record — stating when you last heard from them and a specific date you expect a reply by. Give it a few business days of grace; a genuine emergency looks exactly like a ghosting for the first week. If the deadline passes, you're into a different process, and the recovery playbook lives in why web designers ghost clients mid-project.

A quick word in defense of designers

The internet is full of advice implying that any designer who asks for money upfront is a scammer, and it's worth saying plainly: that's not true. Most designers are honest operators whose worst professional habit is overbooking, not stealing. The structure you want isn't one that assumes bad faith — it's one that works fine if everyone is honest and protects you if they're not. Milestones are exactly that: harmless to a good designer, and the only thing that disciplines a bad one.

Before you pay anyone

Three questions, five minutes:

A designer with clean answers to all three won't mind you asking. The ones who mind are telling you something.

Questions about structuring a project you're starting? We answer every enquiry personally, within one business day.