What should be in a website contract?

Why this matters to both sides

If you are commissioning a site, a contract protects you from losing your domain or being unable to edit your own content.

If you are building sites, it protects you from unlimited revisions, unpaid final invoices and scope that expands quietly for months.

The same six clauses do both. That is what makes this worth agreeing rather than negotiating.

1. Who owns the domain

State it explicitly: the domain is registered to the client's business, and the client has access to the registrar account.

This is the single most common regret in this entire field. Developers register domains on a client's behalf because it is faster, then years later somebody leaves, and an ordinary business is locked out of its own address.

If the developer manages it as a service, say that — and say what happens to it if the relationship ends.

2. Who owns the source files

Be specific, because "you own the website" means different things to different people.

The workable position for most projects: the client owns the design and content created for them, and may use, modify and host it indefinitely. The developer keeps rights to any reusable components, frameworks or libraries they wrote before the project.

That is fair to both sides and it is what most people assume is already true. Write it down anyway.

3. What counts as a revision

The clause that prevents most disputes, and the one most often missing.

Define a number of revision rounds, and define what a round is: consolidated feedback delivered once, not fourteen emails over three weeks. Then define what falls outside — a change of direction, a new page, a new feature — and how that is priced.

Without this, "a few small changes" expands indefinitely and both parties end up resentful. Nobody is acting in bad faith; the term was simply never defined.

4. What happens after launch

The gap that turns a good project into a bad relationship.

• How long are bugs fixed free? Thirty days is common and reasonable.
• Is hosting included, and for how long?
• Who is responsible for updates and security?
• What does a change cost after launch, and what is the response time?
• Is there a support arrangement, and what is in it?

Answer these in the contract and the month after launch stops being an argument about expectations.

5. Payment terms

Standard practice: a deposit to start, one or more milestones, and a final payment on delivery.

Two things worth stating explicitly:

What "delivery" means. Launched, or approved, or handed over? Ambiguity here delays final payments more than anything else.

What happens to unpaid work. If the client stops responding, does the site stay unpublished? Say so plainly, and it will rarely be needed.

6. What happens if either side walks away

The uncomfortable clause that everyone benefits from having.

• If the client cancels mid-project, what is owed for work completed?
• If the developer cannot continue, what does the client receive — files, access, a handover?
• How much notice on an ongoing arrangement? Thirty days is standard.
• Who keeps what: domain, files, hosting, accounts?

Agreeing this while everyone is optimistic takes ten minutes. Agreeing it while someone is angry takes lawyers.

The one-page version

If a full contract feels heavy for a small project, a single page covering these six is genuinely enough:

Ownership. The domain is registered to the client. On final payment, the client owns the design and content and may use and modify it indefinitely. The developer retains rights to pre-existing components.

Scope. [Pages and features]. Two rounds of consolidated revisions included. Anything outside this is quoted separately.

Payment. [Deposit] to start, [balance] on launch.

After launch. Bugs fixed free for 30 days. Ongoing changes at [rate] or under a separate support plan.

Ending it. Either party may end this with 30 days' notice. Work completed is payable. The client receives the source files and all account access.

That is shorter than most templates and covers more of what actually goes wrong.

When the platform answers half of these for you

Three of the six clauses above — who owns the domain, who owns the source files, and what happens if either side walks away — exist because the answers vary. On some arrangements they do not.

If the client is on Helm, the domain is registered in their business name, the code is theirs and can move, and the site and dashboard stay with them regardless of who introduced them. Those three clauses become a statement of what is already true rather than a negotiation, which is worth saying explicitly in the contract anyway: a clause confirming a fact costs nothing and prevents the argument two years later when nobody remembers the conversation.

The other three — revisions, post-launch scope, payment terms — are between you and the client, and no platform settles them. Keep writing those down.