Pay for a website in slices, each tied to a deliverable you have seen and approved — never to a date alone, never all at the end. A fair schedule has three parts: a deposit before work starts, milestone payments against approved stages, and a final payment that releases go-live, logins and ownership. Written down before signing, it protects the buyer from paying for vapour and the builder from building for free.
The short answer: pay in slices tied to approved deliverables, never to dates alone
A deposit of a third to a half is the market norm across staged-payment guides; the simplest structure for a small project is half to begin, half at launch. What matters more than the percentages is the trigger: every payment should follow evidence — a design you approved, a staging link you tested — and the agreement should state what happens if content or payment is late.
The problem: the price was agreed, the payment triggers never were
Most web projects start with a price and a handshake about the rest. Nobody records when design counts as approved, so the builder waits for a verdict that never arrives. Content arrives weeks late, yet the launch date is expected. Then the site is finished and the final payment becomes an argument — buyer wants changes first, builder wants paying first, and neither can point to a line that settles it.
None of this requires bad faith — only a missing schedule. The fix costs nothing: agree the slices, the evidence, and the consequences of delay while everyone is friendly. How the total is calculated is a separate decision, covered in our guide to fixed-price, retainer and time-and-materials models; this article covers timing inside one agreed price.
The three parts of every schedule: deposit, milestones, final payment
A deposit is paid before work starts: it books the builder's time and proves the buyer can pay. A milestone payment is collected when a stage is complete and signed off — design approved, staging build ready. The final payment is the last slice, settled on approval, and the one that should unlock delivery.
Each part has a job. The deposit filters out projects that were never real. Milestones keep the amount invested but unpaid small, so a breakdown costs one slice, not the whole fee. The final payment is the buyer's leverage for a complete handover — and the builder's guarantee that handover happens only once the account is settled.
The common splits compared: 50/50, 50/25/25 and staged quarters (table)
Guides and templates describe three recurring patterns — patterns to compare, not rules. The right one depends on project length and familiarity.
| Split | How it runs | Best suited to | Risk balance |
|---|---|---|---|
| 50/50 | Half before start, half at launch | Small, short, fixed-scope sites | Simple; final slice is large, so the handover checklist matters most |
| 50/25/25 | Half deposit, quarter at design approval, quarter before handover | Fixed-scope design projects (SignlyAI's stage-gated model, via Medium) | Second slice paid only against an approved design |
| Staged / finer splits | Deposit 30–50%, mid milestones of 20–40%, balance on approval (EarnKept guide) | Longer builds, several reviewable stages | Smallest exposure per stage; more admin |
Landolio's freelancer guide adds one discipline whichever split you choose: at least three milestones on anything substantial. On short projects, extra slices create admin — why the 50/50 remains common.
Worked example: a 50%-to-begin / 50%-at-launch project, step by step
WebStackRank publishes its own model, a transparent worked example. On the starter packages — one-page website AED 990, small business website up to five pages AED 2,490, basic business web app AED 4,990 — the structure is 50% to begin and 50% at launch, per the pricing page.
Step by step: you receive an itemised proposal (WebStackRank commits to one within 24 business hours), so the deposit is calculated against named line items. The deposit is paid and work begins. The site is built and reviewed with you. At launch, the final 50% is paid — triggering full ownership transfer of the IP, code and domain. Two payments, two events, nothing owed in between. Larger projects justify finer splits; the principle — payment follows a verifiable event — stays. Sanity-check any quote against our breakdown of how much a website costs.
What each payment should require: approval evidence, staging links, sign-off
A trigger is real if both sides can point to the evidence. For the deposit: the signed agreement and itemised proposal. For a design milestone: a recorded approval — the design files, your written "approved" (email is fine), and the date. For a development milestone: a staging link you can open and test, not a progress claim.
Protect the schedule with an approval window. Templates such as Agiled's use a deemed-approval clause: if no feedback arrives within an agreed number of business days, the deliverable counts as approved and work proceeds. Agree the feedback format too — one set from one named person per round — plus how many revision rounds each stage includes.
The final payment: go-live, logins and ownership transfer as one checklist
The final payment should never be a negotiation — everything it releases can be listed in advance: site live on the client's domain; admin logins handed over and tested; domain and hosting in the client's name or transferred; IP and code ownership transferred on final payment; third-party licences named with their renewal owners; and a handover document covering backups and updates.
Order matters: final payment clears, then transfer happens — the guides are unanimous that files and rights move after the balance lands. Our website handover and ownership checklist covers execution in full; at contract stage, name the final payment as its trigger. Also require the VAT treatment of every amount in writing on the proposal.
Delays, content stalls and change orders: write the consequence before it happens
Three clauses prevent most disputes. First, a content-dependency clause: the client supplies text, images and access by agreed dates; if content is late, the schedule extends. Second, a payment-pause clause: if a milestone payment is overdue beyond an agreed window, the builder may pause work and the deadline moves with the delay. Third, change orders: anything outside the scope is quoted, approved in writing, and paid as an extra milestone or added to the balance.
Escrow is the alternative guides suggest for large projects between strangers: a third party holds funds and releases them on approval. It adds cost and platform rules, so most projects use staged invoicing. This is commercial practice, not legal advice — for anything high-value, have the agreement reviewed under UAE law.
Red flags on both sides (100% upfront, no deposit, payment with no deliverable)
For buyers: 100% upfront with no staged protection; a final payment demanded before you have seen a staging site; ownership wording that leaves the domain or code in the agency's name after full payment; refusal to itemise what each slice buys. For builders: a client who refuses any deposit while pushing for an immediate start, or who will not name an approver.
The shared red flag is a payment with no deliverable attached. If a slice cannot be matched to evidence, renegotiate the schedule, not the price.
Common mistakes
The most common mistake is tying payments to calendar dates instead of approved deliverables, so money falls due whether anything reviewable exists. Next is leaving approval informal — a verbal "looks fine" later withdrawn. Others: no written consequence for late content; change requests handled by message thread with no price agreed; a final payment with no handover checklist, so logins and ownership drift for months. Skipping the deposit removes the project's commitment test. A fixed-price web design structure works when its schedule is written with the same care as its scope.
FAQ
How much deposit is fair for a website project?
Guides and templates consistently describe 30–50% as the normal range, rising for unfamiliar clients and longer timelines. For small fixed-scope sites, 50% is common. Judge the deposit with its triggers: a fair deposit buys a booked start, named deliverables and a written schedule.
Should the final payment be made before or after go-live?
The pattern across staged-payment guides: approve the finished site on staging, pay the balance, then go live and transfer files, logins and ownership. Paying everything before you can test removes your leverage; withholding payment after transfer removes the builder's.
What happens if the client delays content or feedback?
Whatever the agreement says — why the consequence must be written in advance. Standard practice is a dependency clause: the schedule extends by the length of the delay, placeholder content does not count as approval, and long stalls may pause the project. A deemed-approval window stops feedback delays freezing a milestone.
Is escrow better than a deposit for a web project?
Escrow locks the money with a third party and releases it on approval — suited to very large projects between strangers, but it costs commission and follows platform rules. For most projects, staged invoicing under a written agreement spreads risk just as well.
Is a 50/50 split fair to both sides?
For a small, short, fixed-scope project, yes: the buyer risks only half before seeing a finished site, and the builder is never more than half exposed. Its weakness is the size of the final slice — why the handover checklist matters. Longer projects suit finer splits.
See the schedule in a published pricing page (CTA)
Do not take any agency's word for how its schedule works — ask to see it published. WebStackRank's pricing page shows this article's worked example in the open: fixed starter packages, 50% to begin, 50% at launch, full ownership transfer on final payment, an itemised proposal within 24 business hours. Compare every quote against that standard, and use our quote calculator to model your project first.
