Refusing any advance filters out the vendors you actually want and leaves you with the ones desperate enough to accept — then produces a standoff at the end where your last payment and your last change block each other. Stage the payments instead; that gets you the protection you were reaching for.
The moment it happens
“I’ll pay only when everything is done” is a completely rational thing to say, especially after a bad experience or after hearing someone else’s. If the risk is paying and receiving nothing, then not paying until you receive something removes the risk.
It does remove that risk. It creates three others.
Why it backfires
It selects against established vendors. A developer with steady work has no reason to carry a stranger’s project for four weeks unpaid. The vendors who accept zero-advance terms are disproportionately those without enough work to refuse — which is not the group you were trying to reach.
You become the lowest-priority project. Where a vendor has five projects and yours is the only unpaid one, yours is the one that waits. Not malice, just sequencing.
It produces the end-of-project deadlock. This is the most common consequence. At the finish, you have one change outstanding and they have the full amount outstanding. They won’t launch until paid; you won’t pay until it’s right. Both positions are reasonable and the site sits there for weeks. Complaint records show this stalemate repeatedly, and it’s worse than the risk you were avoiding — you’ve paid nothing and you also have no website.
It removes the vendor’s commitment too. An advance binds both parties. Without one, a vendor who gets busy can quietly drop your project at no cost.
What you were actually trying to protect against
Two distinct fears, and they need different remedies:
“They’ll take my money and vanish.” The remedy is a small advance, not no advance. Twenty to thirty percent caps the loss at an amount you can absorb.
“They’ll deliver something bad and I’ll be stuck.” The remedy is staged payments tied to stages you can open on your phone. You stop paying the moment progress stops being visible.
Neither remedy requires refusing to pay anything, and both work better than refusal does.
The structure that actually protects you
| Stage | Payment | What you must be able to see |
|---|---|---|
| Confirmation | 30% | Written scope, invoice, domain in your name |
| Design approved | 30% | Home page design you’ve said yes to |
| Build complete | 30% | Every page viewable on a staging link, on your phone |
| Live and checked | 10% | Site live on your domain, forms tested, logins handed over |
Four things make this work. Each payment follows something you’ve verified yourself. The final 10% is small enough that nobody deadlocks over it. Your maximum exposure at any moment is one stage. And the vendor is paid enough throughout to keep your project a priority.
That last point is the one buyers underrate. A structure that keeps the vendor solvent and engaged produces a better project than one that treats them as a suspect.
The final-10% detail
Keep the last instalment genuinely small — ten percent, not thirty. Here’s why.
If 30% is outstanding at the end, both sides have a lot at stake and each has an incentive to hold. If 10% is outstanding, neither side will spend three weeks fighting over it. The project finishes.
Pair it with one written term: “Final payment on go-live, after I’ve tested the contact form and received the logins.” That’s specific, achievable, and it gives you a defined finish line rather than an open-ended standoff.
When zero advance is reasonable
Two situations:
A very small job. A single page, or a few hours of changes to an existing site. Pay on completion; the amount is small enough that neither side is exposed.
An established relationship. A vendor you’ve worked with before and will again. Trust has been earned rather than assumed.
Outside those, asking for zero advance mainly tells a good vendor to decline politely.
What to say instead
Rather than refusing an advance, negotiate the structure:
Happy to pay 30% on confirmation, with the rest split across design approval, build complete on a staging link I can open, and go-live. Final 10% once I’ve tested the forms and received the logins. Domain registered in my name from the start.
Two effects. Any competent vendor accepts this readily, because it’s fair and it pays them through the work. And you’ve obtained more protection than a zero-advance demand would have given you, without eliminating the vendors worth hiring.
What to do this week
- Register the domain in your own account first — this is the real protection.
- Offer 30% on confirmation rather than nothing.
- Split the balance across three stages you can verify yourself.
- Keep the final instalment at 10%.
- Write down what “go-live” means: live, forms tested, logins received.
If you want it done the certain way
We work on 30% then stage-linked payments, with a small final instalment on go-live after you’ve tested the forms and received the logins — so there’s no standoff at the end. Domain in your name from day one. WhatsApp us; we reply in about five minutes between 9am and 7pm.
Related reading
- How much advance is safe to pay?
- Safe payment milestones for a website project
- The final-10% standoff
- What finally makes a nervous buyer pay?
FAQ
Can I pay a web developer only after the website is finished?
You can ask, but it filters out vendors with steady work and leaves those without enough to refuse. It also creates an end-of-project deadlock where your last change and their full payment block each other.
What’s a fair website payment schedule?
30% on confirmation, 30% on design approval, 30% when every page is viewable on a staging link, and a final 10% on go-live after you’ve tested the forms and received the logins.
Why should the final payment be small?
Because a large outstanding balance at the end gives both sides something to fight over, which is how projects stall for weeks. A 10% final instalment is small enough that neither party deadlocks on it.
