Create a freelance web design contract

A solid freelance web design contract needs nine core sections: scope, payment terms, timeline, revisions, IP ownership, termination, signatures, confidentiality, and dispute resolution. Structure payment as milestones, with a common split of upfront, mid-design approval, and final payment on launch, with a deemed-approval window of a few business days. Start from a template and attach a one-page scope of work rather than drafting a bespoke document for every small-business client.

---

TL;DR:

• Including clear signatory authority and portfolio rights clauses prevents payment disputes and unauthorized use of finished work.
• Tying payment milestones strictly to deliverables with specific dollar amounts and late payment penalties protects freelancers from unpaid work.
• Defining scope, revisions, and change orders with precise language reduces misunderstandings and scope creep.
• Ownership transfers only after full payment ensure freelancers retain rights until final settlement.
• Using templates with AI review and embedded e-signatures streamlines contract creation, reduces errors, and speeds up project initiation.

---

Table of Contents

• How do I create a freelance web design contract for a small business client?
• How do you build the contract from a template step by step?
• What payment schedule and language actually protects you?
• How do you write scope, revisions, and change orders without ambiguity?
• Who owns the site when the project ends?
• Who actually has the authority to sign this contract?
• What protective clauses keep a small project from becoming a big problem?
• How contract tools cut drafting time and catch risk early
• Lessons from standardizing contracts
• Turn your contract template into a repeatable system
• Sources
• FAQ

How do I create a freelance web design contract for a small business client?

Every freelance contract template needs the same skeleton, no matter how small the project or how friendly the client relationship feels at the start. Miss one of these sections and you are the one exposed when a disagreement shows up in month two.

Here is the copy-ready map. Each item below states its purpose in one line so you can paste this straight into a document and start filling in specifics.

• Scope of work and deliverables. Write it like a recipe: exact page count, platform, integrations, and what is explicitly excluded, not a vague "build a website" line.
• Payment terms and milestones. Ties dollars to deliverables, so the client knows exactly what triggers each invoice.
• Timeline with client responsibilities. Covers your delivery dates and equally important, the dates the client owes you content, feedback, or logins.
• Revisions and change orders. Defines how many rounds are included and what happens the moment a request falls outside scope.
• Intellectual property and ownership. States when design files, code, and content rights transfer to the client.
• Termination, kill fee, and cancellation. Protects your time if the client walks away mid-project.
• Signatures and execution. Confirms who is legally allowed to bind the business to the agreement.
• Confidentiality and independent contractor status. Clarifies you are not an employee and protects sensitive business information both directions.
• Dispute resolution and governing law. Names the process and the state whose law applies if things go sideways.

Two items on that list trip up freelancers more than any others. The first is signatory authority: a marketing coordinator signing on behalf of a small business isn't automatically authorized to bind the company, and chasing payment from an unauthorized signature is a real headache. The second is portfolio rights: unless your contract says otherwise, you may not have the right to show the finished site in your own portfolio. Both are cheap to fix in the contract and expensive to fix afterward.

A contract should state obligations only. Language like "the designer should try to deliver by June" is nearly unenforceable, because it describes an intention rather than a duty, according to the Freelancers Union contract creator. Replace every "should" and "could" with "will" or "shall."

How do you build the contract from a template step by step?

Start with a template for small business web design, not a blank page. The AIGA standard agreement is a widely used modular starting point that already covers licensing schedules and IP clauses most freelancers would otherwise draft from scratch. From there, the fastest workflow looks like this:

1. Pick a base template that already has the nine sections above, then strip anything irrelevant to a small-business site build (don't leave e-commerce clauses in a five-page brochure site contract).
2. Write the scope as a recipe. List the platform (WordPress, Shopify, Webflow), exact page count, specific integrations (a booking form, a payment gateway, an email signup), number of revision rounds, and a plain list of exclusions like copywriting or product photography.
3. Set milestones tied to deliverables, not just calendar dates. Payment should trigger on wireframe approval, design approval, and launch, not on "week three" regardless of progress.
4. Add a deemed-approval window. State that if the client doesn't respond within a set number of business days, the current deliverable is considered approved and the project moves forward.
5. Verify who is signing. Get the full legal entity name and the signer's title before you send anything for signature.
6. Attach your supporting documents. A sitemap, wireframes, and written acceptance criteria go a long way toward preventing "that's not what I pictured" disputes later.
7. Send the whole package together: one-page SOW, standard terms, and attachments, so the client reviews everything once instead of piecemeal over email.

Whether you bill fixed-price or hourly depends on how well-defined the scope is. A five-page small-business site with a known feature list works well fixed-price, split across milestones. A project with an open-ended redesign or ongoing content updates is safer hourly, invoiced against a not-to-exceed cap per phase so the client isn't surprised by the total.

Pro Tip: Send the sitemap and wireframes as numbered attachments referenced directly in the contract body ("Attachment A: Sitemap"), not as a separate email. If a dispute ever comes up, you want the visual proof of what was agreed sitting inside the signed document, not buried in an inbox.

A short SOW attached to a set of standard terms saves real time compared to writing a full bespoke contract for every small client, according to Alex Berman's freelance contract breakdown. The terms stay constant; only the SOW changes project to project.

What payment schedule and language actually protects you?

Milestone-based payment is the norm across freelance web design, and for good reason: it keeps you from doing months of unpaid work if a client stalls or disappears.

Common splits break into three shapes, and which one you pick depends on project size and how well you know the client:

• 30/30/40: 30% upfront, 30% at design approval, 40% on launch. Works well for most small-business sites.
• 50/50: Half upfront, half on delivery. Good for short, simple projects under a few weeks.
• 25/25/25/25: Four even payments tied to discovery, design, development, and launch. Better for longer builds with more checkpoints.

Industry guidance generally lands on 25% to 50% upfront with one or two mid-project payments and the balance on launch, alongside a late-payment penalty around 1.5% per month on overdue invoices. That penalty rate is worth stating explicitly in the contract, not implying, because unwritten late fees are functionally unenforceable.

Sample invoice language: "Invoices are due within 10 business days of receipt. Late payments accrue interest at 1.5% per month on the outstanding balance." Sample enforcement language: "Formable will pause all work on the project if any invoice remains unpaid for more than 15 days past its due date."

Milestone math: on a $6,000 project split 30/30/40, that's $1,800 upfront, $1,800 at design approval, and $2,400 due before you hand over the final files. Write the exact dollar amount for each milestone into the contract itself, not just the percentage.

For reimbursable expenses, list them by category (stock photography, premium plugins, hosting setup fees) and require written approval before you spend beyond a set cap, say $150, without checking in first.

How do you write scope, revisions, and change orders without ambiguity?

Vague scope is the single biggest cause of freelancer resentment on small-business projects. Write scope the way a recipe writer would, with quantities and boundaries stated in plain numbers.

A workable sample clause reads: "Designer will deliver a 6-page responsive website on WordPress, including Home, About, Services, three Service Detail pages, Contact, and a blog template, with one contact form integration and one Google Analytics setup." That sentence leaves almost nothing to interpretation.

Revisions need their own definition, separate from new feature requests:

• Revision: an adjustment to an already-delivered element, such as swapping colors, resizing images, or rewording a headline within the approved page structure.
• New feature: anything not in the original scope, like adding an e-commerce cart, a membership login, or a fifth service page beyond what was quoted.
• Included rounds: state a specific number, commonly two or three rounds of revisions per major deliverable, after which additional rounds bill hourly.

Change orders need a short, repeatable process: the client submits the request in writing, you quote the added cost and timeline impact, and the client signs or approves in writing before you touch the work. That approval step is what turns "can you just also add" into a billable line item instead of a source of resentment.

List common exclusions explicitly: copywriting, professional photography, SEO content strategy, third-party app configuration beyond basic setup, and post-launch maintenance. What isn't written down tends to become an argument later, according to practitioner guidance on drafting scope language for web contracts.

Who owns the site when the project ends?

Ownership should transfer on final payment, not on project completion. That distinction protects you if a client tries to walk away with your files before paying the last invoice.

Sample clause: "Upon receipt of final payment in full, Designer assigns to Client all rights, title, and interest in the final website design and content created specifically for this project. Prior to final payment, Client receives a limited license to preview but not publish the work."

A few ownership details are easy to overlook until they cost you:

• Retain rights to your own tools. Frameworks, boilerplate code, and any reusable component libraries you built before this project stay yours, licensed to the client for use within their site only.
• List pre-existing assets separately. If you're reusing a custom WordPress theme you built for other clients, name it in the contract as licensed, not transferred.
• Add a portfolio clause. Something like: "Designer retains the right to display the completed work in Designer's portfolio and marketing materials unless Client requests otherwise in writing."
• Hand over credentials cleanly. Domain registrar access, hosting logins, and CMS admin credentials should transfer at the same moment ownership does, documented in writing.

Who actually has the authority to sign this contract?

Verifying signer authority is one of the most skipped steps in freelance contracting, and it's the reason payment disputes with small businesses drag on. Before you send anything for signature, ask for the client's full legal entity name and the signer's title, and if there's any doubt, request incorporation documents or an email from an address already on record with the business, a step LegalClarity's contract guidance recommends for exactly this reason.

For newer freelance relationships, a W-9 request before the first payment is standard, particularly once total annual payments will cross reporting thresholds.

Electronic signatures are legally valid under the federal ESIGN Act, and most states have adopted the Uniform Electronic Transactions Act, giving e-signed contracts the same enforceability as ink on paper. Use a platform that stores an audit trail, timestamp, and signer IP address so you have evidence of who signed and when if a question ever comes up.

• Record the effective date as the date of the last signature, not the date you sent the document.
• Tie final IP transfer and file handoff to the executed signature plus receipt of final payment, both conditions in one sentence.
• Store the fully executed copy somewhere durable, not just in an email thread you might lose access to later.

What protective clauses keep a small project from becoming a big problem?

A handful of clauses do most of the protective work in a freelance contract, and each one earns its place for a specific business reason.

• Kill fee: if the client cancels mid-project, you are owed payment for completed work plus a percentage, commonly 20% to 50% of the remaining contract value, to compensate for the lost opportunity of turning away other clients.
• Limitation of liability: cap your total liability at the amount the client has paid you. Without this, an unhappy client could theoretically claim damages far beyond what you were ever paid.
• Warranty period: offer a defined window, often 30 days post-launch, to fix bugs that existed at delivery, with anything beyond that billed as new work.
• Confidentiality: a mutual clause protecting both your methods and the client's business information builds trust and heads off disputes over who can say what.
• Independent contractor status: state plainly that you are not an employee, which protects both parties on tax and benefits obligations.
• Dispute resolution: require mediation before either party can file a lawsuit, and name the governing state law upfront so neither side is guessing which court would even hear the case.

How contract tools cut drafting time and catch risk early

Templates get you most of the way there, but the manual parts, tracking redline edits across email threads, chasing signatures, remembering which version is current, are where freelancers lose hours and where mistakes slip through.

Contract workflow software closes that gap. Template generation combined with AI review catches missing clauses (a scope section with no exclusions list, a payment schedule with no late-fee language) before you send anything. Redlining tools with version control replace the "which attachment is the latest one" problem that comes with tracking edits by email, a pain point LegalClarity's drafting guide calls out directly. E-signature and audit trails speed up the final payment step and give you evidence if a dispute ever surfaces.

Formable's contract creator combines templates with generative AI, its redlining tool keeps both sides aligned on one live version, and its embedded e-sign APIs handle execution without leaving your workflow.

Pro Tip: Run your existing contract through an AI review pass before you send it to a new client. A missing kill-fee clause or an undefined revision count is a lot cheaper to catch on your screen than in a dispute three months later.

Lessons from standardizing contracts

Standardizing on a single template and a fixed milestone structure changes how projects feel, not just how they're paperwork. Signoff happens faster because the client knows exactly what triggers each payment. Disputes drop because scope was written like a recipe instead of a vibe. Expectations stay clear because the deemed-approval clause forces a decision instead of a stall.

The freelancers who complain most about scope creep are usually the ones reusing a contract they wrote once, years ago, and never revised. Fix the template once and the arguments mostly stop showing up.

— Alex

Turn your contract template into a repeatable system

Once you have a solid template, the bottleneck shifts to execution: rewriting the same clauses for every new client, chasing redline edits across email, and waiting days for a signature. Formable is the practical next step for freelance designers who want that whole process automated instead of rebuilt from scratch each time. Its contract creator combines your template language with generative AI so a new SOW takes minutes, not an hour of copy-paste.

From there, Formable's AI review flags missing clauses like an undefined revision count or a kill fee with no dollar figure attached, its redlining tool keeps you and the client on one live document instead of five email attachments, and embedded e-signing closes out the deal without a separate tool. If you're comparing signing tools, Formable also works as a standalone e-signing provider with a full audit trail attached to every signature. Before your next client kickoff, try building your next contract from a template and see how much of the drafting work disappears.

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

Sources

• How to Write a Web Design Contract That Protects You - LegalClarity
• Freelance web design contract example + template - Alex Berman
• Contract creator | Freelancers Union
• AIGA standard agreement

FAQ

Can I legally write my own contract?

Yes. There's no requirement that a lawyer draft your freelance contract, and using a well-built template like the AIGA standard agreement or the Freelancers Union contract creator is common practice. Have an attorney review any unusual terms or high-value projects before you sign.

How much should I charge per hour for web design?

Hourly rates vary widely by experience, region, and project complexity, and this article doesn't have a sourced benchmark figure to cite. Base your rate on your target monthly income divided by billable hours, then compare informally against similar freelancers in your market.

What are the 7 rules of a contract?

There's no single universally agreed "7 rules" framework, and definitions vary by source. The core elements courts generally look for are offer, acceptance, consideration, mutual consent, capacity, legality, and a defined scope of obligations, all of which the nine-section structure above already covers.