Freelance Web Developer Contract: What to Include

A generic freelance services contract covers the basics — scope, payment, timeline — but web development work has a handful of specific failure points that a generic template doesn't address. Most of them surface after launch, not during the build, which is exactly when an undefined contract is hardest to fix. Here's what to add, and how to get it signed.

Where generic contracts fall short for dev work

Who owns the code, and when. "Client owns the work" sounds simple until you're using a component library you built for another client, or a client assumes they own your internal tooling too. Be explicit: does ownership transfer on full payment, or on delivery? Does it cover only the custom code you write, or also third-party libraries, themes, and plugins you integrate (which you usually can't transfer ownership of — only a license to use them)? A client who later wants to resell or relicense the codebase needs a different, broader agreement than standard project ownership.

Browser and device support scope. "The site should work" is not a spec. Without a stated support matrix (e.g. "latest two versions of Chrome, Safari, Firefox, Edge; not IE11"), you can end up debugging edge cases indefinitely on client hardware you were never told about. State the matrix explicitly, and state that anything outside it — a five-year-old Android device, a corporate browser locked to an old version — is out of scope unless specifically requested and quoted.

Hosting, domain, and account handoff. Who registers the domain and hosting account — you or the client? If it's registered under your account "for convenience," put in writing how and when it transfers, so a payment dispute doesn't turn into the client's site going offline because you control the login. This is one of the most common leverage disputes in freelance web work, and it's entirely preventable with one clear sentence in the contract.

Third-party services and their ongoing costs. Most projects depend on paid services beyond hosting — a CMS license, an email API, a payment processor, a mapping API. State who pays for these ongoing costs: the client directly (usually cleaner, since they keep the account), or a pass-through where you invoice for them. Don't let "included in the project fee" quietly become "the developer eats recurring SaaS bills forever."

Revisions vs. new scope. Define what counts as a revision (fixing something against the original spec) versus a new feature request (a new spec, billed separately). Without this line, "just one small change" requests can consume unpaid hours indefinitely — and in dev work specifically, a "small" UI change request can hide a non-trivial backend change that only becomes visible once you're already implementing it.

Acceptance criteria and sign-off. Define what "done" means for each milestone — specific, testable criteria tied to the spec, not a subjective "client is happy with it." Without this, final payment can get stuck in an open-ended review cycle where every round of feedback surfaces a new, previously unstated expectation.

Post-launch support window. Bugs found in week one after launch feel different from a client asking you to debug a year-old site for free. State how long post-launch fixes are included, and what happens after that window closes — including whether it's a flat window (30 days) or scoped to specific severity (critical bugs only, for longer).

Source code and asset delivery. Specify exactly what gets delivered — source files, a Git repo, hosting credentials, documentation — and when. "The client gets the code" is not the same as "the client gets a working local build with a README, deployment instructions, and environment variable documentation" — the difference is what makes a handoff to another developer feasible instead of a multi-day archaeology project.

How this differs by project type

• Marketing/brochure sites. Lower technical risk overall, but browser/device support matrix and content-update ownership (can the client edit copy themselves, or does every change route through you) matter more here than elsewhere.
• Web applications. Acceptance criteria and a defined testing process matter most — "it works" needs to mean something specific and verifiable, not a subjective client impression after clicking around for ten minutes. Data migration and backup responsibility also need explicit ownership if the app handles user data.
• E-commerce builds. Third-party payment processor integration, PCI-compliance responsibility (usually handled by the processor, but say so), and inventory/catalog data ownership need their own lines — plus a clear answer for who's on the hook if a payment integration bug causes a financial loss during a launch-week sale.
• Ongoing maintenance retainers. Shift the contract's center of gravity from a fixed spec to a monthly scope of hours, response-time expectations for urgent fixes (a payment bug at 2am is not the same priority as a typo), and what counts as included maintenance versus new-feature work billed separately.

A practical structure

1. Scope of work, referencing a spec or wireframes as an attachment.
2. Browser/device support matrix.
3. Payment schedule (deposit, milestones, final payment on delivery).
4. IP ownership terms — custom code vs. third-party licenses.
5. Third-party service costs and who bears them ongoing.
6. Acceptance criteria for each milestone.
7. Revision limits and how additional scope is billed.
8. Post-launch support window and what it covers.
9. Delivery format for source code, credentials, and documentation.

SignFastAi's free Creative & Web Design Services Agreement template already covers ownership, usage rights, revisions, and a kill fee — use it as your starting point and add the browser-support, hosting-handoff, and acceptance-criteria specifics above for a web project.

What a code-ownership clause actually looks like

"Client owns the final product" is too vague to prevent the disputes described above. A version that actually holds up reads something like:

This draws the actual line: custom code transfers, pre-existing tools and third-party licenses don't, and it protects your ability to keep building your own toolkit across clients — something a bare "client owns everything" sentence quietly signs away.

A real-world example

A freelance developer builds a booking web app for a small fitness studio, with Stripe for payments and a third-party calendar API for scheduling. The contract states that final payment transfers ownership of the custom application code, but not the Stripe or calendar API integrations themselves (licensed under their own terms), that the studio pays Stripe and the API vendor directly for ongoing usage, and that acceptance requires the studio successfully completing a test booking and a test payment before final invoice. Two months after launch, the studio wants to hire a different developer to add a feature. Because the original contract required a README, deployment documentation, and full repo access as part of delivery, the new developer is able to pick up the project in an afternoon instead of a week — and the original developer isn't the one fielding support calls for a project they're no longer being paid to maintain.

Getting it signed without slowing the project down

Once the contract's ready, the same two-minute link-based signing flow works here as for any other freelance agreement: upload the PDF, mark the signature fields, and send a secure link — no printer, no account required for the client. See how freelancers get contracts signed faster for the full workflow, and is an electronic signature legally binding if a client asks whether it holds up.

Once the contract's signed, a free estimate or invoice for the project takes about the same two minutes.

Related guides

• Freelance Bookkeeper & Accountant Contract Guide
• Freelance Consultant & Coach Contract Guide
• Freelance Virtual Assistant Contract Guide
• Freelance Translator Contract: What to Include

Common questions

Who owns the code after the project is delivered? This should be explicit in the contract — whether ownership transfers on full payment or delivery, and whether it covers only custom code or also third-party libraries and plugins.

What counts as a revision versus a new feature request? A revision typically means fixing something against the original spec, while a new feature is a new spec that should be billed separately — the contract should define this line clearly.

How long is post-launch support usually included? This varies by contract, but it should state a defined window for included bug fixes before further work is billed separately.

Who registers the domain and hosting account? The contract should specify whether the developer or client controls this, and how it transfers if registered under the developer's account.

Who pays for third-party APIs and paid services the project depends on? State this upfront — the client typically pays ongoing subscription costs (hosting, a paid API, a CMS license) directly, or reimburses the developer, rather than assuming they're bundled into the project fee.

What does acceptance testing look like before final payment? Define specific acceptance criteria tied to the original spec — a client testing against requirements that were never written down is how final sign-off gets stuck in an open-ended review loop.

What happens if the client wants to hire a different developer later? Documentation and a clean handoff should be part of delivery, not a separate paid request — a project without a README, deployment notes, and clear repo access is much harder (and more expensive) for anyone else to pick up.

Send your next web development contract with SignFastAi — free to start, no credit card required.