here is no universally correct website deposit because projects differ in length, certainty, team size and procurement process. The safer question is whether the payment schedule shares risk sensibly and corresponds to work you can recognise. A deposit reserves capacity and funds mobilisation; it should not be a substitute for a clear scope, named milestones or evidence that the supplier can deliver.
Before design appears, a supplier may schedule people, decline other work, run discovery, prepare environments and begin research. A deposit makes that commitment mutual. For a short, well-defined project it may represent a larger share because mobilisation is a larger part of the whole. For a longer programme, smaller staged payments often align cash more closely with delivered value.
- Deposit: capacity is reserved and the agreed start conditions are met.
- Discovery milestone: requirements, risks, content and success measures are documented.
- Design milestone: representative screens and the visual system are approved.
- Build milestone: the agreed functionality works in a reviewable staging environment.
- Handover or launch: final checks, access, documentation and outstanding balances are completed.
Those labels are examples, not a required formula. The important part is that each stage has an acceptance method. A payment tied only to “week four” can become due even if an approval dependency or supplier problem means there is little to inspect.
- A very large non-refundable payment before scope and responsibilities are written down.
- Payment requested to a person or account that does not match the contracting supplier.
- No description of refunds, cancellation, pause rights or ownership of part-completed work.
- The final payment is due before credentials, source files or launch responsibilities are handed over.
- Artificial urgency that prevents references, identity, terms or the proposal from being checked.
An attractively small first invoice does not help if later milestones are vague, essential work is excluded or the supplier controls the domain and hosting. Compare the total committed cost, the conditions that unlock each invoice, third-party fees and the cost of reaching a usable launch. The payment plan should sit inside a complete commercial picture.
Use a written agreement, pay against invoices, keep business accounts under business control and document approvals in a shared channel. If the project changes, approve the effect on price and schedule before the extra work begins. A professional supplier should be comfortable explaining why its payment structure exists and what the client receives at each point.
Payforcommitmentanddemonstratedprogress—notforreassurancealone.
The percentage matters less than what triggers it. A reasonable deposit reserves capacity and funds early discovery. Later invoices should correspond to an approved direction, demonstrated working scope, a launch candidate and handover—not merely dates on a calendar.
- Deposit: signed agreement, scheduled team and discovery start.
- Direction: approved brief, architecture, risks and design system.
- Working product: agreed priority journeys demonstrated in a shared environment.
- Launch candidate: content complete, acceptance checks run and known issues documented.
- Handover: production release, client-owned access and agreed documentation delivered.
Contracts should also explain change control, delayed client inputs, cancellation, correction periods and third-party costs. Avoid both extremes: paying everything before evidence exists, or requiring a supplier to finance the entire build until launch.