Most small business owners spend weeks comparing portfolios, reading reviews, and sitting through pitch calls before hiring a web designer. Then they spend about four minutes on the contract — skim it, sign it, move on. That order is backwards. The portfolio tells you what an agency can build. The contract tells you what happens when something goes wrong, and something almost always does.

I run a digital marketing agency, so I've read more of these contracts than I'd like to admit — both the ones we write and the ones clients bring us after a previous project went sideways. The pattern is consistent: the problems that end up costing real money were sitting in the contract the whole time, in language that sounded standard enough to skim past.

Who actually owns the website once it's built?

This is the single most expensive thing small business owners get wrong, and it's rarely explained clearly upfront. In U.S. law, the default assumption is that whoever creates a work owns it — not whoever paid for it. Unless your contract explicitly assigns ownership of the code, design files, and content to you, the designer may legally retain those rights even after you've paid in full.

Watch for two specific traps. First, platform lock-in: some agencies build your site on a proprietary or heavily customized platform that only they can edit, so leaving them means rebuilding from scratch. Second, a "buy-back" clause that requires an additional licensing fee to take full ownership of your own site — I've seen this run $1,500 to $4,000 on top of what the client already paid to build it. Neither of these is illegal. Both are avoidable if you read the ownership clause before you sign, not after you try to leave.

The contract should state plainly that all deliverables — source code, design files, content, and login credentials — transfer to you upon final payment, with no separate fee and no dependency on staying with that agency for hosting or maintenance.

Why is the scope of work always so vague?

"We'll design and build a modern, professional website" is not a scope of work. It's marketing copy. A real scope specifies the number of pages, whether it includes a blog or e-commerce functionality, how many rounds of revisions are included, and what counts as a change request versus new work.

Vague scope is where "scope creep" invoices come from. You ask for what feels like a reasonable tweak — a new page, a different checkout flow — and three weeks later you get a bill for $600 in "additional development" you never agreed to. Ask for the scope in writing with specific deliverables listed, and ask what the process is for anything outside that list: a fixed hourly rate, a change-order form, something you approve before work starts. If a designer resists putting a real scope in writing, that reluctance is the answer to how the rest of the project will go.

What happens if you need to cancel halfway through?

Almost nobody asks this before signing, and it's the clause that matters most when a project isn't working. Look for three things: the termination notice period, what you owe for work completed if you cancel, and whether you keep anything that's been built so far.

Some contracts include a "kill fee" — a set percentage owed if you cancel early, on top of milestone payments already made. That's not automatically unreasonable, but it needs to be a specific number you agreed to, not something calculated after the fact. I've also seen contracts where canceling forfeits everything built to that point, even work you already paid for. That's a red flag regardless of how the rest of the agreement reads.

Why does the payment schedule matter more than the total price?

A 50% deposit with the balance due on completion is standard and reasonable. A demand for 100% upfront, before you've seen a signed contract or a single wireframe, is not — it removes your only real leverage if the work doesn't match what was promised. Milestone-based payments (deposit, midpoint after design approval, final payment on launch) protect both sides and give you natural checkpoints to walk away if something's off.

This is one reason every contract we write at Sun BPO Solutions ties payment to specific milestones and assigns full ownership of code and content to the client the moment the final invoice clears — no buy-back clause, no separate licensing step. That's not a special favor; it's the standard any contract you sign should meet, whoever you end up hiring.

What does "ongoing support" actually include after launch?

Plenty of contracts mention post-launch support without defining it, which lets an agency interpret "support" as generously or as narrowly as suits them later. Get specifics: does support include security updates and plugin patches, or only fixing bugs the agency itself introduced? Is there a monthly hour allotment, and what happens once you exceed it? Is hosting bundled in, and can you take your site to a different host if you leave?

If the contract is silent on this, assume "support" means nothing enforceable, and budget for a separate maintenance conversation once the site launches.

Five questions to ask before you sign anything

Use these as a pre-signature checklist, not a formality:

  1. "Who owns the code, design files, and content once I've paid in full — and is that written into the contract?" The answer should be immediate and unqualified.
  2. "What exactly is included in the scope, and what happens if I need something outside of it?" You want a specific list and a defined change-order process, not "we'll figure it out."
  3. "What's the payment schedule, and what am I owed or what do I owe if I cancel at the midpoint?" Get the cancellation terms in writing, not verbally promised.
  4. "Can I take this site to another developer or host if I ever need to?" If the answer involves a platform only they control, factor that into your decision now.
  5. "What does post-launch support cover, and what's it cost once the included period ends?" Get the hour allotment and hourly rate in writing.

The bottom line: the contract is not paperwork standing between you and the fun part of the project. It's the only document that protects you once the relationship gets difficult — and most web design relationships hit at least one rough patch. Read the ownership, scope, cancellation, and payment sections before you sign anything, and don't treat a designer's hesitation to put specifics in writing as a minor detail. It's the clearest signal you'll get before you've spent a dollar.

Ramesh M is the founder of Sun BPO Solutions and has reviewed and negotiated web design contracts for small business clients since 2015. He leads the editorial team at Signal Daily News.

FAQ

By default under U.S. law, whoever creates the work owns it — not whoever paid for it. Unless your contract explicitly assigns ownership of the code, design files, and content to you upon final payment, the designer can legally retain those rights. Always confirm ownership terms are written into the contract before signing.

A deposit of 30–50% upfront, a payment at the midpoint after design approval, and the balance due on launch is standard and protects both parties. Be wary of any agency demanding 100% payment before you've seen a signed contract or any project work.

Some agencies build sites on proprietary or locked platforms and charge an additional licensing fee — often $1,500 to $4,000 — for the client to gain full ownership or move the site elsewhere. This should be avoided; ownership should transfer automatically upon final payment with no separate fee.

Treat it as a serious warning sign. A vague scope like 'design a modern website' with no specifics on pages, features, or revision limits is how scope-creep invoices happen later. Ask for a written, itemized scope and a defined change-order process before signing anything.

This depends entirely on the termination clause, which most business owners never read before signing. Check the required notice period, whether you owe a cancellation fee (sometimes called a 'kill fee'), and whether you keep any work already completed and paid for.

Yes. Contracts that mention 'ongoing support' without defining it let the agency decide later what that means. Get specifics in writing: whether security updates are included, the monthly hour allotment, the hourly rate once that period ends, and whether hosting is bundled or portable.