Web project contracts: the clauses that keep you out of disputes

On a web project, most disputes don’t start with a technical fault but with a disagreement over what was promised. A clear contract isn’t there to win a lawsuit — it’s there to avoid one. Here are the clauses that, on a build or design engagement, stop today’s vagueness from becoming tomorrow’s conflict.

#Define the scope, and above all its limits

The first source of tension is scope. A quote that lists features without saying where they stop leaves the door open to silent expansion: the famous “one small extra” that, repeated, eats the margin. A scope clause describes the expected deliverables, but it also names the exclusions and the working assumptions — the targeted CMS version, the content supplied by the client, the supported browsers.

Anything outside that frame goes through a change order: written, priced and signed before work starts. There’s nothing bureaucratic about it — it turns a tense end-of-project negotiation (“but I thought that was included”) into an explicit decision made at the right moment. The contract benefits from separating deliverables from mere means, and from spelling out acceptance: how many rounds of review, within what time the client signs off, what happens when there is no reply.

#Payment: deposit, milestones and retention of title

A web project is rarely paid in one go. The deposit on order — often thirty to forty percent — commits the client and covers the ramp-up. The balance is split into milestones tied to concrete deliverables, not arbitrary dates. Tying a payment to an acceptance phase rather than to the 15th of the month avoids financing a client’s slowness out of your own pocket.

Two clauses complete the setup. Late-payment penalties are a reminder that supplier credit isn’t free. A retention-of-title clause states that the deliverables remain the provider’s property until full payment: as long as the invoice is unpaid, the transfer of rights and the go-live have not taken place.

A signed quote counts as a contract, but it stays silent on the touchy points — and that is exactly where disputes take root.

#Intellectual property: who owns what

Code and creative work don’t transfer to the client automatically just because they pay. Under French law, an assignment of author’s rights must be written and bounded: which rights, for which media, which territory, what duration. A serious web contract separates three layers. The bespoke work produced for the engagement is assigned to the client, usually on full payment. The provider’s reusable building blocks — a component foundation, an internal library — remain their property and are granted under a usage licence. Third-party dependencies keep their own open-source licences, which the contract does well to mention so there is no ambiguity about what the client may redistribute.

The same logic applies to visuals, fonts and content: an image licensed for a website isn’t necessarily licensed for a derived mobile app. Naming those limits protects the client as much as the provider, who has no interest in assigning rights they don’t hold.

#Liability, data and reversibility

No serious provider promises flawless software. A limitation-of-liability clause caps the compensation, often at the value of the engagement, and excludes indirect damages such as loss of business. It goes hand in hand with an honest definition of warranties: fixing defects during a warranty period is one thing; ongoing maintenance is another, and belongs in a separate contract.

Two topics deserve their own clause. The first is data protection: as soon as the provider processes personal data on the client’s behalf, the GDPR requires a processing agreement that sets out each party’s obligations. The second is reversibility: at the end of the relationship, the client must get back their code, credentials, data and documentation in a usable format. Spelling out what “hand back” means — a Git repository, hosting credentials, a database export — avoids the accidental hostage-taking of a project by whoever holds the keys.

#Ending the contract: parting without breaking everything

A project can stop before its term: shifting client priorities, a lasting disagreement, insolvency. A termination clause sets out who can end the contract, with what notice and what financial consequences. The fair principle is simple: work done and accepted is owed, so are costs already incurred, and the matching deliverables are handed over in proportion to payment. Separating termination for convenience — the client changes their mind — from termination for cause stops one being used as an alibi for the other.

Two points attach usefully here. A non-solicitation clause frames the mutual poaching of teams during and after the engagement. And a mediation clause, requiring an attempt at amicable settlement before any court action, costs a few lines and often saves months of proceedings: it’s the clause you hope never to read, and the one that makes the others breathable.

#The bottom line

A good web contract isn’t a defensive document written against the client: it’s a shared frame that makes explicit the decisions the excitement of kickoff leaves in the dark. Scope and change orders for reach, deposit and retention of title for money, a bounded assignment for intellectual property, limitation of liability and reversibility for the exit: these six points cover most of the situations that, with nothing in writing, end in a standoff.

The ideal contract stays short and readable. Five clauses understood and respected beat a legal wall of text no one rereads — and which, when the day comes, protects only the person who wrote it.

Further reading: mandatory mentions and clauses of a professional contract (service-public.fr, in French).