Verdict: Milestones tied to stages you can open on your phone — 30% on confirmation, then design, then build, then a small 10% on go-live. Never 100% upfront to anyone; and 100% at the end repels the vendors you actually want.
The side-by-side
| 100% upfront | 100% at the end | Milestones (30/30/30/10) | |
|---|---|---|---|
| Your maximum exposure | Everything | ₹0 | One stage |
| Vendor’s commitment secured | Fully | None | Fully |
| Good vendors accept it | Some will ask | Most decline | Yes, readily |
| Who you attract | Anyone | Those with no other work | Competent vendors |
| Your project’s priority | Depends | Lowest — the unpaid one | Normal |
| Risk of end-of-project deadlock | Low | Highest | Low — final is only 10% |
| You can stop when progress stops | No | N/A | Yes |
| Best for | Never | A tiny job, or an existing relationship | Almost every project |
Why 100% upfront is never right
Simple: it transfers everything to the vendor before anything exists. Complaint records document the pattern — advance paid, work begins or doesn’t, replies slow, then stop. And refund policies are near-universally absent from small website offers here, so recovery isn’t the plan.
If someone asks for the full amount before starting, that request is itself the answer.
Why 100% at the end backfires
This is the counter-intuitive one, and it’s the confirmed pattern.
It filters out the vendors you wanted. Picture two developers receiving your proposal. The one with four paying projects would have to carry a stranger’s work for four weeks unpaid, against a completion condition you define. They decline politely, and you never learn why. The one with no work accepts, because a possible payment beats none.
So the term acts as a filter, pointing exactly the wrong way.
You become the unpaid project. Where a vendor has five projects and yours is the only one with no money in it, yours waits. Sequencing, not malice.
It creates the deadlock. The most common outcome, and documented. At the finish you have one change outstanding and they have the entire amount outstanding. They won’t launch unpaid; you won’t pay something unfinished. Weeks pass. You’ve paid nothing and you also have no website — which is worse than the risk you were avoiding.
It removes their obligation too. An advance binds both parties. Without one, a developer who gets busy can drop your project at no cost — no refund to make, nothing at stake.
The structure that works
| Stage | Payment | What you must be able to see first |
|---|---|---|
| Confirmation | 30% | Written scope, GST invoice, domain in your name |
| Design approved | 30% | A home page design you’ve said yes to |
| Build complete | 30% | Every page viewable on a staging link, on your own phone |
| Live and checked | 10% | Live on your domain, forms tested, all logins received |
Four properties make this work:
- Each payment follows something you verified yourself — not a date, not a description.
- Your exposure at any moment is one stage, not the whole project.
- The final instalment is small enough that nobody deadlocks over it. Ten percent isn’t worth a three-week standoff to either side; thirty percent is.
- The vendor is paid through the work, so your project stays a priority rather than becoming the charity case.
The final 10% detail
Worth isolating, because it’s what prevents the most common bad ending.
Keep the last payment genuinely small, and define what triggers it in writing:
Final payment on go-live, after I’ve tested the contact form and received the registrar, hosting and admin logins.
That gives you a defined finish line instead of an open-ended standoff, and it gives them a defined thing to deliver. The final-10% standoff in detail.
What actually protects you — ranked
Payment structure is item two, not item one:
- Register the domain in your own account, before hiring. ~₹1,000/yr, ten minutes. Converts the worst case from losing your business name to losing an advance. No payment term achieves this.
- Advance of 20–30%. Caps the maximum at risk.
- Stage-linked balance. Caps how far a failure can progress.
- Written scope — pages, revisions, date, year-two cost.
- GST invoice, and check the account holder name your UPI app shows matches the invoiced firm.
Note item 1. A zero-advance demand does nothing about the most expensive risk in the transaction.
Choose milestones if…
- It’s a normal website project with a defined scope and a delivery date
- You’re a first-time buyer, or you’ve been burned before
- You want to be able to stop the moment progress stops being visible
- This is almost everyone reading this
Choose zero advance if…
Two genuine cases, so this isn’t absolute:
- A very small job — one page, or a few hours of changes to an existing site. The amount is small enough that neither side is exposed.
- An established relationship where trust has actually been earned over previous work.
Outside those, the demand mostly tells a good vendor to decline.
Choose 100% upfront if…
Never. If someone asks for the full amount before starting, that request is the answer.
The message to send
Happy to pay 30% on confirmation, with the balance split across design approval, all pages viewable on a staging link, and go-live. Final 10% once I’ve tested the contact form and received the logins. Domain registered in my name from the start, and please send the GST invoice for the advance.
Any competent vendor accepts this readily — it’s fair and it pays them through the work. Resistance tells you which term they need you to give up, and that’s usually the one that matters.
What to do this week
- Register your domain in your own account before paying anyone.
- Offer 30%, never more, and never zero.
- Split the balance across three stages you can verify on your phone.
- Keep the final instalment at 10% and define what triggers it.
- Check the account holder name matches the invoiced firm before confirming.
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
- Hiring a website developer: what to check before you pay advance
- Should you pay only after the site is perfect?
- Is your website advance “gone money”?
- Safe payment milestones for a website project
- The final-10% standoff
FAQ
How should I pay a web developer?
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. Each payment follows something you verified yourself.
Is it safer to pay a website developer only at the end?
No. Established vendors decline the arrangement, so it filters toward those who can’t refuse it, and it produces an end-of-project deadlock where your last change and their full payment block each other.
Should I ever pay 100% upfront for a website?
No. It transfers all risk before anything exists, and refund policies are near-universally absent in this market. A request for the full amount before starting is itself the answer.
Why should the final instalment be small?
Because a large outstanding balance at the end gives both sides something to fight over, which is how projects stall for weeks. Ten percent isn’t worth a standoff to either party.
