Most disputes about outsourced work are arguments about a sentence nobody wrote.

A scope that describes activity instead of output cannot be finished. "Development of the client's website" is an activity; it has no end state, so any moment can be argued to be either complete or incomplete depending on who benefits.

The test is arithmetic: can a stranger read the clause and count the things? "All necessary pages" cannot be counted; eleven can. Anything genuinely unknown at signature should be named as unknown and priced separately, rather than hidden inside a word like "necessary" that each side reads in its own favour.

The same test applies to any domain. A data job says how many records and in what format. An illustration job says how many pieces at what dimensions. A translation job says the word count and what happens to text found in images.

This is the clause most often missing entirely, and its absence is what turns a finished project into an indefinite one. Without it, delivery has no legal effect: the supplier believes they delivered, the client believes they are still reviewing, and the final payment sits between the two positions for months.

An acceptance clause needs three parts. A criterion — what the deliverable must do to be accepted, ideally the same list as the scope. A window — how long the client has to test it. And a default — what happens if the window passes in silence.

Rejection should have to be specific. A clause that lets the client reject the whole deliverable citing general dissatisfaction gives one side a veto with no obligation to explain it; requiring rejection to identify which listed criterion is unmet keeps the conversation about the agreed list rather than about taste.

"Two rounds of revisions included" sounds precise and is not, because the argument is never about the number. It is about what a round is.

That last row matters more than the count. If bug fixes consume the included revisions, a supplier is financially rewarded for delivering fewer defects only in the sense that they keep their own rounds — and a client who reports genuine errors is spending their allowance on them. Separating errors from changes is what makes the number honest.

Almost every remote engagement stalls on something the client owes: copy, photographs, logins, a decision, sign-off from a third person who was never in the room. Contracts routinely list the supplier's obligations in detail and the client's not at all, which makes every delay look like the supplier's.

• List each input by name and owner. "Final text for pages 1-6, from the Client's marketing lead" is checkable. "Content" is not.
• Attach dates to inputs, not only to outputs. A schedule where only the supplier has deadlines is not a schedule.
• State the consequence. "Each working day of delay in a Client input moves subsequent milestone dates by one working day" is neutral, mechanical, and prevents the compression that normally lands on the last stage.
• Name the approver. One person, by role. Work approved by someone without authority gets re-approved by someone with it, and the second review is where scope creeps.
• Cover access. Credentials, environments, VPN, whatever is needed — and who to contact when access fails on a Friday afternoon.

None of this is defensive lawyering. It is the difference between a delay everybody understood in advance and a delay that arrives as an accusation.

Two separate questions hide inside the word "ownership", and conflating them causes trouble years later, usually when the client wants to move to another supplier.

The first is what transfers. Bespoke work made for this engagement can transfer outright. Things the supplier brought with them — an internal library, a reusable component, a base template — usually cannot, and should not be pretended otherwise. The honest structure is: the client owns the deliverable, and receives a perpetual licence to any pre-existing material embedded in it. A contract claiming the client owns everything including the supplier's toolkit is either untrue or means the supplier cannot work for anyone else again.

The second is what was never either party's. Fonts, stock images, icon sets, third-party libraries and plugins come with their own licences. Those licences do not transfer just because the invoice was paid, and web fonts in particular are commonly licensed by page views or by domain. A clause requiring the supplier to list every third-party asset with its licence and licensee prevents the client discovering, later, that they are using a font nobody bought for them.

The project can be complete, paid, and accepted, and the client can still be unable to change a word on their own site a year later. Handover is what prevents that, and it has to be enumerated because anything unlisted will be the thing that is missing.

One note on domains, because it surprises people: registrar policy imposes waiting periods after a fresh registration and after a change of registrant, during which a move between registrars can legitimately be refused. A name opened on the supplier's account at kick-off therefore cannot always be released the week the project closes. The clean answer is to register it in the client's own name on day one and skip the problem entirely.

Termination clauses get skipped because negotiating them feels like predicting failure. They are read only when the relationship has already broken down, which is exactly why they must be written when it has not.

Three things need answering. What is owed — work completed to date, at what rate, and whether partial milestones are payable. What is handed over — normally the same list as clause six, applied to whatever exists at that point. What is destroyed or returned — client data, credentials, and access, with a deadline.

Add a notice period proportional to the engagement and require termination in writing. And separate ordinary termination from termination for cause: the first is a business decision either side can take, the second follows a breach that was notified and not fixed within a stated window. Collapsing them into one clause means every exit becomes an accusation.

A last practical point: keep the document short enough that both sides have actually read it. A seven-clause statement of work that is understood beats a forty-page agreement that was skimmed, because the clauses above only work if the people doing the work know they exist.