Plain-English guide · free
Web Design Contract Red Flags & What to Include
A web design contract is the document that decides who owns the site, who gets paid when, and what happens if the project drags on or falls apart. Most disputes between designers and clients trace back to something the contract never spelled out clearly.
This guide walks through what a solid web design contract should cover, the clauses that tend to burn the smaller party (usually the freelancer or agency, sometimes the client), and what to check before you sign anything.
Don’t just read about red flags — find the ones in your contract.
Upload your web design & development contract and PlainClause gives you a plain-English review — what you’re signing, every red flag, and what to negotiate. Your first preview is free.
Get your free review →What is a Web Design & Development Contract?
A web design and development contract is an agreement between a designer/developer (or agency) and a client for building, redesigning, or maintaining a website. It typically covers what's being built, the timeline, payment terms, who owns the final product and code, how revisions are handled, and what happens if either side wants out early. You'd sign one for anything from a simple brochure site to a custom web application — the stakes just get higher as the project gets bigger.
Scope of Work & Deliverables
This section defines exactly what's being built: number of pages, specific features, e-commerce functionality, custom code versus templates, and what's explicitly excluded. Vague scope is the single biggest source of disputes — 'a modern, responsive website' means something different to everyone.
Good contracts attach a detailed spec or statement of work, list what counts as a deliverable, and define what 'done' looks like. If the scope only lives in email threads or verbal conversations, it's not really defined at all.
Payment Schedule & Late Fees
Look for a clear payment schedule tied to milestones (deposit, midpoint, delivery) rather than one lump sum at the end. This protects the developer from doing months of work with nothing to show for it if the client disappears.
Check for late payment consequences — interest, work stoppage rights, or late fees — and whether the contract says what happens if the client simply stops responding partway through.
Ownership, IP & Licensing
This is where a lot of confusion happens. Contracts should state clearly when ownership of the final website, custom code, and design files transfers to the client — ideally upon final payment, not before. Work handed over before the client has paid in full gives up leverage.
Separately, designers often reuse their own pre-existing tools: code snippets, frameworks, plugins, or design systems built before this project. The contract should distinguish between newly created work (which transfers to the client) and pre-existing IP (which the designer keeps and merely licenses for use in the site).
Revisions, Approvals & Change Orders
Every project needs a revision process: how many rounds are included, how feedback gets submitted, and what counts as a 'revision' versus a 'new request.' Without this, small tweaks can spiral into an unpaid redesign.
A change order clause — a simple process for pricing and approving work outside the original scope — keeps scope creep from being absorbed for free.
Termination, Kill Fees & Post-Launch Support
Projects get cancelled. The contract should say what happens if either party wants to end things early: what's owed for work completed, whether a kill fee applies, and who keeps the work-in-progress files.
It should also be clear about what happens after launch — is there a warranty period for bug fixes, and is ongoing maintenance covered here or in a separate agreement? Open-ended 'support' language with no time limit or scope can turn into free, indefinite labor.
Red flags to watch for
Unlimited revisions with no cap or definition
Without a defined number of revision rounds or a distinction between 'fixing what was agreed' and 'new requests,' a client can keep sending changes indefinitely and the developer absorbs the cost.
Full payment due only on 'client satisfaction' with no objective completion standard
This lets a client withhold final payment indefinitely by simply saying they're not satisfied, with no defined standard for what finished work looks like.
IP assignment clause that sweeps in the developer's pre-existing code, frameworks, or tools
Broadly worded ownership clauses can accidentally transfer rights to code, templates, or systems the developer built long before this project and plans to reuse elsewhere.
No termination or kill fee clause
If the client can cancel at any point without paying for work already completed, the developer carries all the risk of a project that stalls or gets abandoned midstream.
Ownership of the finished site transfers before final payment clears
Handing over source code, hosting access, or admin credentials before payment is complete removes the developer's main point of leverage if the client stops paying.
No liability cap, or liability tied to the full value of the client's business
A developer with no cap on damages could be on the hook for losses far exceeding what they were ever paid for the project, especially if the client's business suffers unrelated losses.
Vague scope description with no attached spec or feature list
Without a documented scope, 'the project isn't finished' becomes a matter of opinion, and disagreements about what was promised are hard to resolve.
No indemnity for content the client supplies
If the client provides images, text, or logos that turn out to infringe someone else's copyright, an unclear contract can leave the developer exposed for using material they didn't create.
What to look for before you sign
- Is the scope of work detailed and attached as a spec, not just described in a sentence or two?
- Is the payment schedule tied to milestones, with a deposit before work starts?
- Does ownership of the final site and code transfer only after final payment clears?
- Is there a clear line between the developer's pre-existing tools/code and newly created deliverables?
- Is the number of revision rounds defined, with a process for pricing anything beyond that?
- Is there a termination clause that says what's owed if either side ends the project early?
- Is there a liability cap, and does it seem proportionate to what's being paid?
- Does the contract say what happens after launch — warranty period, bug fixes, ongoing maintenance?
- Are third-party costs (hosting, plugins, licenses, stock images) clearly assigned to one party?
- Is there a clause covering who's responsible if client-supplied content infringes someone else's rights?
Got a web design & development contract in front of you? PlainClause reads your actual document and finds the red flags in about a minute.
Review your contract free →Frequently asked questions
Who owns the website after it's built?
It depends entirely on what the contract says. Most well-drafted contracts transfer ownership of the final deliverables to the client once payment is complete, while the developer keeps rights to any pre-existing tools, frameworks, or code they reused. If the contract is silent, ownership can be genuinely unclear.
What's a reasonable number of revisions to include?
There's no universal standard — it depends on project size and complexity. The important thing isn't the exact number, it's that a number (or clear boundary) exists at all, so both sides know when 'revising the design' turns into 'requesting new work.'
Should a web design contract include a kill fee?
Many do, and it's a reasonable ask from the developer's side. A kill fee compensates for work completed and momentum lost if the client cancels partway through, and it gives the developer some protection against open-ended, unpaid effort.
Do I need a separate contract for ongoing maintenance after launch?
It's common to handle maintenance and support in a separate, renewable agreement rather than bundling it into the build contract. If it's included in the original contract, make sure it has a defined time limit and scope so it doesn't become indefinite free support.
Can a client use my code or design after they stop paying me?
This usually depends on when the contract says ownership transfers. If ownership is tied to final payment and payment was never completed, the client generally shouldn't have full rights to the work — but this depends on the specific wording and where you are, so it's worth reading that clause closely.
Key takeaways
- A vague scope of work is the root cause of most web design disputes — get specifics in writing, not just a general description.
- Ownership of the final site and code should transfer on final payment, not before — this is the developer's main leverage.
- Cap revisions, define 'done,' and build in a change-order process so scope creep doesn't become free labor.
- Look for a termination/kill fee clause and a liability cap — both protect against worst-case scenarios on either side.
- Post-launch support should have a clear time limit and scope, or it can turn into indefinite unpaid maintenance.
More guides
This guide is general information to help you understand a common type of contract — it is not legal adviceand doesn’t cover your specific situation or local laws. For a high-stakes contract, consult a lawyer.