Contract Red Flags: What Not to Sign

A web design contract is supposed to be the part of the project that prevents disputes. Too often it's the part that causes them — because the terms were written to protect the designer from you, not to protect the project for both of you.

You don't need a lawyer to review a website contract. You need to know which clauses deserve a hard look before you sign, and which ones are simply the cost of doing business. Here's the field guide.

The red flags that should stop you

Everything registered in the designer's name.

If the contract puts the domain, the hosting, or the site's code under the designer's personal or agency accounts — with no clause specifying how and when you get access — you're not buying a website. You're leasing one, indefinitely, from someone who controls the off-switch.

This is the single most consequential structure in the entire agreement, because it determines what happens when the relationship ends. Not if — when. Designers retire, move, get sick, get busy. The contract should say your domain is registered in your name, your hosting is in your account, and you can walk away with everything. We cover the full picture in who really owns your website.

Full payment upfront.

A contract that asks for 100% of the project cost before work begins isn't protecting anyone's cash flow — it's removing yours entirely. Deposits are normal and fair. The structure matters: milestone-based payments keep both sides honest in a way that a single large payment never will. We walk through the options in website deposits and milestone payments.

Vague deliverables.

"The Client shall receive a modern, responsive website." That sentence has never prevented a single dispute. A contract should specify what pages, what features, what's included in SEO work, and what happens when the answer to a question is "that's extra." Every deliverable should be countable. If you can't tell whether something was delivered, you can't tell whether the contract was honored.

No termination terms.

What happens if the project stalls? What do you owe, what do you keep, and who owns the work completed so far? A contract without a termination clause assumes the project will finish. Ask anyone who's been ghosted mid-project how that assumption holds up.

Work that exists only on the designer's computer.

A more modern version of the ownership problem: the contract is silent about where the work lives. If the code, the design files, and the content exist only in the designer's workspace — not a shared, client-accessible location — then the project's continued existence depends on one person's hard drive and one person's continued responsiveness. The contract should require client access from day one, not client access on request.

Unlimited "free" work.

"Unlimited revisions" and "free changes for life" are not generosity. They're either unpriced line items that will eventually be priced — or marketing language for a service you'll have to fight to use. The revision terms should be specific: how many rounds, what counts as a round, and what extra work costs. More in "unlimited revisions" and other fine print.

What a good contract includes

The absence of red flags isn't the same as the presence of a good agreement. A contract you can trust has these things, in plain language:

The best contracts we've seen run four or five pages. A contract that's forty pages of dense clauses usually isn't protecting you from risk; it's hiding risk inside language you won't read.

What's normal and fair

To keep this balanced — because not every unfamiliar clause is a trap:

Deposits are normal. Designers take on real risk of client vanishing, scope creep, and non-payment. A deposit structure isn't a red flag; a structure that puts all the risk on one side is.

Monthly care plans are normal. Ongoing maintenance for an ongoing fee is a legitimate service, and it can be genuinely valuable. The test is the term: month to month is a service you're choosing; a multi-year lock-in is a service you're trapped in. We've written before about what websites actually cost in this market, including why a studio confident in its work doesn't need a lock-in clause.

Scope-change clauses are normal. Projects change as they take shape. A clause that says changes are quoted before work begins isn't a trap — it's how a fixed price stays fixed. The trap version charges retroactively for anything not specified in the original document, down to the comma.

The five-minute review

Before signing any web design contract, run this checklist:

If a contract answers all five cleanly, sign it. If it answers three and hand-waves the other two, the hand-waved ones are where the dispute will come from.

One more thing

Read the contract the same week you receive it — not the day before the project starts. Most bad contracts aren't malicious; they're templates nobody updated. Asking a designer to clarify or adjust a clause before signing is a normal professional request, and how they respond to it tells you exactly how the next six months of change requests will go.

Questions about a contract you've been sent? We'll read it with you. We answer every enquiry personally, within one business day.