Web design contract: what yours should say

The short answer

A web design contract should say exactly what is being built, who owns each piece when it is finished, how and when payments are due, how changes are handled, what launch includes, what happens when something breaks afterward, and how either side can end the agreement and leave with what was paid for. If any of those is missing or vague, ask for it in writing before you sign.

Most of the trouble I see later traces back to something nobody wrote down: a domain registered in the designer’s account, a revision promise with no limit, or no plan for after launch. I am a web designer, not a lawyer. This is a checklist for reading a contract, not legal advice, and anything binding or unusual deserves an attorney’s review. It is not a contract either: who owns what in your project depends on the written agreement you both sign.

Scope: what is being built

The scope is the heart of a web design contract. Everything else, from price to timeline to what counts as a change, depends on it. A good one lists:

• Pages and page types, one by one, so nobody argues later about whether the gallery was included.
• Features, each named: contact forms, a store, bookings, a members area, connections to other systems.
• Content: who writes the words, who supplies photos, and by what date.
• What moves from the old site, and how the move is checked.
• Devices and browsers the site is tested on.
• Search setup at launch: redirects from old addresses, titles and descriptions, Search Console.
• Any accessibility or speed target, if you need one.
• What is not included, in writing, so nobody is surprised.

If you are a larger organization collecting proposals from several firms, the website RFP template helps you get scopes you can compare.

Ownership of the domain, hosting, code and accounts

This is the clause people skip and regret. What follows describes common arrangements; in your project, ownership is whatever your signed agreement says. Check each piece separately.

• Domain. It should be registered to your business, in a registrar account you can log in to. The contract should say so. You can check where yours stands today with the domain ownership lookup.
• Hosting. Whose account is it, who pays, and what do you receive if you leave? The answer should be a complete copy of the files and the database, in a form any host can restore.
• Design and custom code. Under US copyright law, work made by an outside contractor generally belongs to the person who made it unless a signed written agreement transfers it; 17 U.S.C. 204 requires a transfer to be in writing and signed. The label work made for hire only applies to certain categories of commissioned work, and only with a signed agreement, as the Copyright Office’s Circular 30 on works made for hire explains, so many web contracts use a written assignment or a clear license instead. The contract should say which one you get, and when it takes effect.
• Custom plugins. If the site depends on code written for it, you need either ownership or a permanent license to keep using and changing it.
• The designer’s own tools. Reusable code a designer uses across many clients is usually licensed to you, not transferred. That is normal, as long as the license is permanent and lets someone else maintain the site.
• WordPress itself is released under the GPL, so nobody can own your copy of it in a way that locks you out.
• Accounts. Owner access to Google Analytics, Search Console and your Business Profile should be yours.

The full piece-by-piece list is in who owns your WordPress website.

Content, photos and licenses

• Words you wrote are yours. Words written for you should become yours once they are paid for, and the contract should say so.
• Stock photos are licensed, not owned. Ask whose name the license is in and whether it covers ads and social media as well as the website.
• Commissioned photos and video usually stay the photographer’s copyright with a license to you. Make sure the license covers every place you plan to use them.
• Premium themes, plugins and fonts come with license keys that pay for updates. Ask for a list of each one, whose license it runs on, and when it renews.

Payments, in plain terms

Payment terms vary, and that is fine. What matters is that they are clear. A typical structure ties payments to milestones: something to start, something at an agreed midpoint such as design approval, and the balance at launch or acceptance. Whatever the shape, the contract should state:

• What triggers each payment, in terms you can both verify.
• When invoices are due and what happens if one is late.
• What happens to the work if the project pauses for weeks because content or decisions are not ready.
• Which third-party costs you pay directly, such as hosting, the domain and licenses, and in whose name they are bought.
• When ownership transfers. Many contracts transfer it on final payment, which is reasonable if it is written down.

Changes, revisions and delays

• Rounds of revisions. How many are included at each stage, and what one round means. Unlimited revisions sounds generous and usually leads to arguments.
• Change versus fix. A fix corrects something that does not match the agreed scope. A change adds or alters scope. The contract should say how each is handled.
• Change requests in writing, with the effect on price and schedule agreed before the work happens.
• Delays on both sides. If content arrives a month late, the launch moves. If the designer is late, you should know what happens too.

Launch and acceptance

Launch should be defined, not assumed. A good contract lists what launch day includes: pointing the domain, HTTPS, redirects from old addresses, testing forms and checkout on the live site, and connecting Search Console and analytics. My website launch checklist shows what that looks like in practice.

It should also say how acceptance works: how long you have to review the finished site, how you report problems, and what counts as done.

Warranty, support and care after launch

Two different things often get blurred here.

• A warranty period covers defects in the work that was delivered: something built that does not work as agreed. The contract should say how long it lasts and what it excludes, such as changes you or a plugin make later.
• Ongoing care covers updates, backups, security, monitoring and small changes for as long as the site runs. That is a separate agreement with its own term, its own price and stated response times.

If the same person handles both, the contract should still list them separately, so ending one does not quietly end the other. That is how I run WordPress maintenance and managed WordPress hosting.

Termination: how to part ways cleanly

Nobody likes writing this clause, and everybody is glad it exists. It should cover:

• How either side can end the agreement, and with how much notice.
• What you pay for work already done.
• What you receive, and how fast: files, database, logins handed over, and help moving the domain or hosting.
• What happens to backups and copies of your data afterward.

Alongside it you will usually see limits of liability, confidentiality, and which state’s law applies. Those are the parts where an attorney’s eye is most useful.

Red flags in a web design contract, and how I write mine

Slow down if you see any of these:

• The domain or hosting will be in the designer’s name with no transfer clause.
• The scope fits on one line.
• Nothing says what you own at the end.
• Unlimited revisions, or no revisions defined at all.
• No mention of what happens after launch.
• No way to leave with a working copy of your site.
• A promise of the top spot on Google.

For what it is worth, here is how I handle my own. Every project gets a written scope and a flat quote before any work starts, with hosting and ongoing care listed separately from the build. The domain stays in the client’s registrar account and points where they tell it. And the person who writes the scope is the person who builds the site. If you are still choosing who to hire, how to choose a Louisville web designer has the questions to ask first.

Frequently asked questions

Do I need a contract for a small website project?

Yes. Even a short agreement signed by both sides, listing the scope, the payments and who owns what, prevents most misunderstandings. Small projects need it as much as big ones.

Who owns the website design after I pay?

Whoever the contract says. Under US copyright law the creator generally owns the work unless a signed written agreement transfers it, so look for a clear assignment or license and when it takes effect.

Is a web design contract template enough?

A template is a starting point. It still has to describe your actual scope, your payment terms and your ownership, and for anything unusual an attorney should review it.

Should hosting be in the same contract as the build?

It can be, as long as it is its own section with its own term and price. That way ending hosting does not end your rights to the site, and finishing the build does not end the hosting.

What if my designer will not hand over my files?

Start with the accounts in your name: the domain registrar and the hosting. Then look at the termination and ownership clauses. If the domain is yours, you can always point it somewhere new.