The contract clauses I added after three years of client websites

I write code. I did not expect to spend so much of my career thinking about
contracts.

Three years ago my client agreement was two paragraphs in the body of an email.
It said what I'd build and what it cost. Every clause I've added since then went
in because something specific went wrong, and I'd rather you learn them from a
blog post than the way I did.

Not legal advice — I'm a developer, not a lawyer. Have someone qualified in your
country read anything before you rely on it.

1. Scope, with a "not included" list

The included list is the easy part. The not-included list is what saves you:
logo design, copywriting, photography, hosting fees, email migration, stock
images, ongoing maintenance.

Clients don't read "not included" as hostile. They read it as someone who has
done this before.

2. Payment in three parts

50% before work starts, 30% at design approval, 20% before launch.

The deposit isn't a formality. It's the difference between a client who is
committed and a client who is exploring options.

3. The deposit is non-refundable once work begins

You turned down other work to hold those weeks. That's what the deposit pays for.

4. Late payment stops work

Not "may stop work". Stops. And the timeline moves by at least the length of the
delay — your calendar doesn't grow a free week later just because they were slow.

5. What the client owes you, with actual dates

Content, logo files in vector format, hosting and domain access, feedback within
a set number of working days. Put real dates next to each one, in the proposal,
before anyone signs.

6. The content delay clause

If I could keep only one clause, it would be this.

If content is more than X days late, the project goes on hold, and the invoice
for work completed to that point becomes due. It rejoins my schedule when I have
room — which might be weeks later.

This sounds harsh until the third time a project dies because nobody wrote the
About page. Almost every stalled project I've had stalled on content, not code.

7. Revision rounds, and a definition of "round"

A round is one consolidated set of feedback. Five emails over three days is five
interruptions, not one round, and if you don't define it you will be the one
absorbing the difference.

8. Change requests in writing, before any work

Client asks. You reply with cost and timeline impact. They confirm. Then you
start.

This isn't bureaucracy, it's protection in both directions. They never get a
surprise invoice and you never do unpaid work. Small things I still absorb
without mentioning — the clause exists for the "while you're in there, can we
add a booking system" requests.

9. Silence counts as approval

If I ask for sign-off and hear nothing for X working days after one reminder,
that stage is approved and we move on.

Without this, one unresponsive client freezes your schedule indefinitely and
you have no way to restart it.

10. Ownership transfers on final payment

Until the last invoice clears, the work is mine. The site goes live when payment
does.

This is the single most effective clause for getting a final invoice paid, and
it has never once caused an argument with a client who intended to pay.

11. One named decision-maker

When feedback arrives from four people who disagree with each other, someone on
the client's side has to resolve that before it reaches you. Name that person in
the contract.

12. What happens if either side walks away

They pay for work completed. Anything prepaid and not yet worked against comes
back. Agreeing this while everyone is still friendly takes five minutes;
agreeing it afterwards takes a lawyer.

None of this makes you difficult to work with. In my experience it does the
opposite — clients relax when the person building their site clearly knows how
projects go wrong, because it suggests you've finished a few.

What's in your contract that isn't in mine? I'm still adding to this.