What to Look For in a Web Development Contract

A web development contract is the document that decides who owns your site after launch, what happens when the project slips a month, and what you can do if the agency disappears with your deposit. Most small business owners read it once, sign it, and find out two months in that the answers are not what they assumed.

Here are the clauses that matter, what each one is supposed to do, and what to push back on before signing.

Scope of work

The scope is the spine of the contract. If it is vague, every other section breaks under it. A workable scope answers four questions on one page or less:

1. What pages or templates are being built?
2. What features are included (contact form, blog, e-commerce, scheduling, etc.)?
3. What is being supplied versus what the client supplies (copy, images, brand assets)?
4. What is explicitly out of scope?

The "out of scope" line is the one most owners skip. Without it, every grey-area request becomes a disagreement. A vague scope reads "modern, mobile-friendly website with up to ten pages." A real scope reads "five fixed templates: Home, About, Services, Contact, and a Blog index. Blog includes 8 starter posts. E-commerce, multi-language, and member portals are out of scope and quoted separately."

Ownership and intellectual property

The biggest contract surprise is that a website built for you is not automatically yours. Under U.S. copyright law, the person who creates a work owns the copyright unless a written agreement says otherwise. The U.S. Copyright Office's Circular 9 on Works Made for Hire lays out exactly how a work-for-hire arrangement has to be documented to transfer ownership to the hiring party. Verbal handshakes do not count.

Your contract should explicitly state:

• The client owns the final deliverables (page templates, copy written for the project, images licensed for use on the site).
• The client is granted a license to any third-party assets used (stock photos, fonts, plugins) for use on this specific site.
• The developer retains rights to general code patterns, libraries, and tooling reused across projects, but the client owns anything project-specific.
• Domain name and hosting accounts are owned by the client, not the developer.

The last point is the one that bites small businesses hardest. If the developer registers your domain in their account "to make things easier," you do not actually own your domain. Always register the domain in your own name with your own credit card.

Payment terms

A normal small business web contract uses a milestone payment schedule:

• 30% to 50% deposit before work starts
• A second payment at design approval or development midpoint
• Final payment due before the site goes live

Watch for two patterns that signal trouble. First, "100% upfront" is a red flag for any project over a few hundred dollars; you have no recourse if the work stalls. Second, "monthly retainer with no scope" charges you a recurring fee with no defined deliverables. Retainers are fine for ongoing care plans, but they should specify hours or tasks per month.

The contract should also spell out late fees, what happens if a milestone is missed, and how change orders get priced (hourly rate, minimum charge, written approval before work).

Timeline and delays

A real timeline includes both the developer's commitments and the client's. Most projects do not slip because the developer was slow. They slip because the client took three weeks to send copy, then another two to approve the design.

Look for clauses that:

• List milestones with target dates
• Define what counts as "client delay" (for example, more than five business days to provide requested feedback or assets)
• Pause the timeline when client delays happen rather than penalizing the developer
• Cap the total project timeline so a stalled client engagement does not become a year-long obligation

Revisions and change orders

Every project gets revisions. The contract should define:

• How many rounds of revision are included per stage (design, content, development)
• What counts as a revision (text edits, color tweaks) versus a change order (adding a page, swapping the homepage layout, adding a feature)
• The hourly rate or fixed price for change orders
• That all change orders must be in writing and approved before work begins

Without this language, every "small tweak" becomes an argument about whether it was included.

Hosting, domain, and third-party accounts

Independent of who builds the site, decide upfront who owns the accounts. The IRS defines independent contractors by who controls the work, not who owns the tools. Your developer is almost certainly an independent contractor, which means accounts they create on your behalf can legally remain in their name unless the contract says otherwise.

Specify in writing:

• Domain registration is in the client's name with the client's billing
• Hosting account is in the client's name (or transferred at handoff)
• All third-party accounts (Google Analytics, Search Console, email service, payment processor) are owned by the client
• Admin credentials are handed off in writing at project completion

Termination and exit

If the relationship ends mid-project, what happens? A reasonable termination clause includes:

• Either party can terminate with 14 to 30 days written notice
• Client pays for work completed up to the termination date
• Developer hands over all source files, design assets, and credentials in a usable format
• Both parties agree to a transition period if the client wants help moving to a new vendor

Watch for "no refund" clauses that pair with vague scopes. Those exist to protect agencies from the consequences of their own missed deadlines.

Compliance and accessibility

The web is regulated, even if most small business owners do not realize it. The U.S. Department of Justice's web accessibility guidance clarifies that the ADA applies to business websites, and the standard most courts reference is WCAG 2.1 Level AA from W3C. Privacy laws (CCPA, GDPR if you have any EU traffic) layer on top.

Your contract should answer:

• Will the developer build to WCAG 2.1 Level AA standards?
• Who is responsible for privacy policy, terms of service, and cookie disclosure language?
• Is ongoing accessibility maintenance included or out of scope?

If accessibility is out of scope, that is fine, but it should be stated, not assumed.

Liability and warranty

A reasonable warranty clause covers bugs in the developer's work for 30 to 90 days post-launch at no charge. Beyond that, fixes come from a care plan or hourly rate. Liability should be capped at the contract value or a reasonable multiple, not unlimited. And the contract should be governed by the law of one state (usually the developer's), with disputes resolved in that state's courts or by binding arbitration.

What we put in our contracts

At Mecha Data we use the same baseline for every project: written scope with explicit out-of-scope items, milestone payments, full ownership transfer at final payment, named timeline with mutual delay pauses, two rounds of revision included per stage, client-owned domain and hosting accounts, 60 day post-launch bug warranty, and WCAG 2.1 Level AA as a build standard. If you are reviewing a contract from another agency and want a second set of eyes before signing, contact Mecha Data. We will read it for free and flag any clauses that look unusual for a small business engagement.