The question that decides everything
Every web development dispute reduces to one question: who owns what, from the moment money changes hands. Contracts that answer it badly — or vaguely — produce the horror stories: sites held hostage, licenses surfacing years later, businesses rebuilt from scratch because the exit was never designed.
This guide is not legal advice; it is the checklist of what to ask a lawyer (or your developer) to look at. The five clauses below decide 95% of outcomes.
1. IP assignment — on payment, not on completion
The contract should say intellectual property transfers to you upon payment, per milestone or per invoice. "On completion" means a mid-project dispute leaves you owning nothing built so far. "On final payment" is acceptable; "on final payment including the maintenance retainer" is hostage-taking with paperwork.
Check the carve-outs too: third-party libraries stay under their licenses (normal and fine — you still have the right to use and modify the delivered work), but your business logic, design and content must be unambiguously yours.
2. Source access — from day one
Non-negotiable clause: you have access to the repository, the deployment pipeline and all credentials from the start of the engagement. Not "on completion." Not "for a fee." The scenario this protects against is not hypothetical and not rare: developer disappears, dispute arises, or you simply want to move on — and the exit is impossible because nothing was ever in your hands.
A developer who resists repo access is telling you how the relationship ends. Believe them.
3. Milestones — money follows proof of work
Structure payments against deliverables you can verify: design approved, staging site live, content migrated, launch complete. Deposits are normal (10–50%); full payment upfront is not. The milestone schedule also gives you the exit ramp: part ways at any gate, pay for what is verified, keep what is built.
4. The change mechanism — priced honestly, in writing
Scope changes are certain; the only question is whether they are handled or improvised. The contract should define how changes are requested, priced and approved before work begins on them. "We're flexible" is not a mechanism — it is an invoice you have not seen yet, in both directions.
5. Warranty and post-launch — what "done" includes
A defined warranty window (30–90 days is standard) where defects are fixed at no cost. After that: a maintenance posture in writing — what it covers, what it costs, how it cancels. "Done" should also mean documented: the handover includes credentials, architecture notes and a runbook, because a website nobody can operate is not delivered.
Red flags in the small print
- Perpetual licenses — you "license" your own site from the developer, forever. Occasionally legitimate (SaaS-style arrangements), usually a trap.
- Non-competes aimed at you — clauses preventing you from hiring anyone else to work on the site you own.
- Unlimited liability caps in the developer's favour — normal to cap their liability; abnormal for the cap to be the contract value while yours is unlimited.
- "Tools and internal libraries remain ours" — fine for genuine internal frameworks, dangerous when it describes the majority of your codebase. Ask what fraction of the delivered work this covers.
The five-minute pre-signature checklist
- IP transfers on payment — per milestone. ✔
- Repo + credentials + pipeline access from day one. ✔
- Milestones you can verify, deposit ≤ 50%. ✔
- Written change mechanism with priced approvals. ✔
- Warranty window + documented handover as a deliverable. ✔
Five ticks or no signature — whoever the developer is, whatever the price. Every engagement described on this site runs on exactly these terms; start a project and the contract you receive will match this list line for line.