Code ownership: the clause that matters most
The single most important thing to verify in any web development contract is who owns the code when the project is done. This is not a question with an obvious answer, and the legal default is not what most clients assume.
US creators ordinarily own their work; full payment doesn't necessarily transfer rights to own, share, or modify code. Work-for-hire applies automatically to employees, not contracted freelancers/agencies, where explicit language still faces legal uncertainty. Require ownership of everything built after final payment plus backup assignment if work-for-hire fails in court. Both clauses protect ownership regardless of that ruling.
Switching developers in three years requires transferable code without permission. Licenses may fail when developers close, change careers, or stop responding; retained copyright also creates dispute leverage. Business buyers' due diligence values outright website ownership more than permission to use it.
Require final-payment ownership of code, design files, graphics, databases, and custom software. Standard portfolio-display rights may remain with developers. Identify off-the-shelf/open-source components governed by separate licenses versus custom work you own.
Confidentiality should cover proprietary logic, pricing, intake, and other accessed business information. Confirm this standard clause survives project completion reasonably; immediate expiry offers no protection against later disclosure to competing clients.
Domain and hosting ownership
Code ownership is legally complex; domain ownership causes more immediate damage. Clients commonly lose domains through unwritten assumptions made at project outset.
Register domains in your own name, email, and registrar account, never a developer's, agency's, or unknown reseller's. Loss threatens your brand, website, and every domain email. Recovery without provable account ownership is slow and uncertain; even successful ICANN disputes take months and money.
Developers may manage domain settings or host your site, but registration must stay in your name/account. Ask explicitly if not offered. Claims that one developer-owned account is "easier" signal broader ownership concerns.
Know hosting credentials, backup locations, and exit arrangements. Require complete files/data within a defined period, generally five to ten business days, whenever the relationship ends. Written handoff terms establish professional separation before strained relationships make it difficult.
Document domain-setting control, certificate management/annual renewal, and contingency if a developer's reseller account closes or is suspended. These real scenarios otherwise turn transitions into website/email outages with unclear server control.
Scope definition: what you are buying
Vague scope causes most development conflicts: ten pages expected versus four delivered, email forms charged extra, or revisions billed as new work. "Professional website" is an aspiration, not a contractual definition.
List pages/purposes: Home, About, Services, three detail pages, Contact, Privacy Policy. Specify email forms, maps, galleries, phone/tablet layouts, and basic SEO; name custom code, WordPress/theme, or builder. Explicitly include/exclude scheduling, payment, and customer-database integrations, with later costs/implementation. "Add later" is inadequate for launch-critical scheduling.
Define included revision rounds and a round, commonly one feedback batch per section. Distinguish copy/button-color edits from added services, approved-navigation restructuring, or unplanned features. Otherwise each request becomes a negotiation over extra charges.
Assign copy and image responsibilities explicitly. Set content deadlines and consequences: proportional delays, placeholders replaced later, or extra fees. Three weeks awaiting About copy can stall projects despite developer readiness. Any agreed remedy is fairer than silence.
Change orders and out-of-scope requests
Scope defines work included at the agreed price; change orders govern everything outside it. Contracts need both before disputes make the distinction urgent.
For requested or mutually agreed scope changes, the developer first writes work, cost, and schedule effects. Client approval in writing, including email, precedes work, billing, or timeline changes. This prevents surprise invoices and documents authorization for every extra charge.
Without change orders, small undocumented favors accumulate unpaid work and resentment, or retrospective charges surprise clients. One contractual paragraph prevents both strained-relationship scenarios.
Specify flat, hourly, or day rates for extras beforehand. "Two hours at $X" then replaces post-work price negotiations. Request missing terms; professionals have standard rates and should willingly name them.
Payment structure and milestone payments
Payments reveal risk allocation and working incentives. Nearly full upfront payment burdens clients; delaying most compensation until launch burdens developers. Balanced structures avoid both problems.
For $2,800–$5,000 projects, typical payments are 30-50% at signing, another after approved staging, and balance after final launch approval. Larger jobs may use three or four payments, adding mockup or pretesting completion. Exact splits matter less than keeping payment aligned with delivered progress.
Be cautious above 50% upfront: 75% or 100% leaves little leverage for late, wrong, or absent work. Conversely, almost no deposit may signal instability causing delays, disappearing communication, or rushed shortcuts. Modest deposits establish mutual commitment.
Define cancellation payments: retained versus prorated deposits if you stop, and refunds if the developer stops/fails. Written answers prevent later disputes; experienced professionals should have established cancellation terms.
Confirm methods and fees, often 2.9-3.5% for cards. Ask about bank transfers before signing. Card issuers' dispute rights for partially completed work vary; verify yours.
Timeline, milestones, and what happens if they slip
Web development projects run late. This is common enough that it is almost the expected outcome on projects without explicit timeline accountability built into the contract. The question is not whether there will be delays, but whether the contract gives you any meaningful recourse when delays become significant, and whether the timeline was realistic at the point of signing.
Date kickoff, mockups, staging, revisions, and launch. Define client approval and feedback deadlines at every checkpoint as well as developer delivery. Slow, vague, or changing feedback otherwise stalls reviews.
Ask how the developer estimated the timeline. Realistic schedules allow design iteration, revisions, content delays, and testing. A two-week estimate for a multi-page site with custom functionality suggests either close experience with that scope or underestimation. Ask about recent comparable builds, their durations, and common causes of overruns. Vague or evasive answers reveal their approach to accountability.
Specify missed-milestone grace periods and remedies: written extensions, delay refunds, or termination with prorated refunds for undelivered work. Bare launch dates offer little enforcement. These terms aren't universal but aren't unusual; request them before signing when timing matters.
Post-launch support and warranty terms
Contracts must extend beyond launch: mail configuration, booking API updates, and browser changes expose untested failures. Define who handles these inevitable issues and the cost.
Seek 30–90 days of free fixes for promised features failing in the agreed hosting environment. Warranties cover delivered work, not breakage from your added plugins/tools, code edits, or hosting changes.
Define bugs versus additions: undelivered form emails are bugs; new fields are features. New-device layout failures may be bugs under responsive commitments or features for previously nonexistent categories. Written classification processes and out-of-warranty rates prevent gray-area disputes.
Define support after warranty: fixed monthly hours or hourly extras, with prices or confirmation of an established rate. If unavailable, say so; plan another developer and retain files/instructions for handoff.
Assign post-launch WordPress/platform security and add-on updates. For developer hosting, document how to request complete data/site backups. Set both terms before launch, not after separation.
Liability caps, IP indemnification, and dispute resolution
The back section of a web development contract (the legal boilerplate that most people skim) contains clauses that are worth reading carefully. Not because every project ends in a legal dispute, but because understanding what you are agreeing to changes how you evaluate the overall fairness of the terms.
Liability caps commonly limit developers to project fees, a reasonable, widely accepted approach generally enforceable in most jurisdictions. Developers usually cannot cover consequential losses such as customers or business days. Require reciprocity; unlimited client exposure paired with capped developer liability warrants challenge.
Third-party ownership protection assigns copyright/trademark claim responsibility for stock photos, icons, code libraries, fonts, and templates. Improper commercial licensing can trigger legal fees/damages. Developers should protect you for materials they supply; clauses requiring you to defend their choices shift their mistakes onto you.
Dispute resolution may mean direct talks, mediation, binding private arbitration, or court. Common arbitration is faster/cheaper but forecloses small claims, often simplest for $1,200–$5,000 disputes.
Check governing law and venue. Florida clients accepting another state's terms face that legal system. It's not disqualifying; request your state's law where possible. Most developers agree, also valuing local jurisdiction themselves.
Negotiating contract terms: what to push back on and how
Many clients treat a developer's contract template as a take-it-or-leave-it document, which it is not. A contract is a starting point for negotiation, and a professional developer will expect that you have read it and may have questions. The key is knowing which terms are negotiable versus which are structural to how the developer runs their business.
Terms that are almost always negotiable: which state's law applies, the payment schedule (within reason), how long the post-launch warranty lasts, how scope changes are handled, and what counts as a revision. These terms have no right answer from the developer's perspective, and changing them does not require the developer to change how they do the actual work.
Require code assignment and domain registration in your name; reject refusal. Check reciprocal liability caps. Retained developer ownership complicates every future change, developer switch, and business sale, unacceptable for paid custom work.
Request specific changes directly: IP assignment after payment, or replacing 60% upfront with 40% signing, 30% staging, 30% launch. Professionals usually accommodate familiar, reasonable requests. Hostility reveals useful information before payment.
Review privately, list desired changes, and send a targeted written proposal for two or three terms. Heavily marking up everything signals conflict; focused requests invite straightforward responses.
Red flags that tell you to walk away
Some warning signs are visible in the contract itself. Others appear earlier, in how the developer communicates before anything is written down. Both matter, and neither set should be rationalized away because the price seemed right or the portfolio looked impressive.
- Refusing to use a contract at all. This is the clearest signal that a developer is either inexperienced or operating in a way that benefits from the absence of written terms. A professional web developer who has shipped multiple client projects has standard contract language covering scope, IP assignment, payment milestones, and post-launch support because they have been burned by not having it. Without a written contract, there is no defined scope to point to when a client asks for a seventh revision, no IP clause to enforce when you need to hand the code to a new developer, and no written record of what the project cost if the developer later claims additional work was authorized verbally. A developer who resists any written agreement ("I work on trust," "let's just see how it goes," "we can formalize later") should not receive any money from you.
- No visible portfolio of live, functional websites. Ask for URLs and visit each one in a browser. Open the browser's developer inspection panel (a built-in feature available in every modern browser) and look for any broken features, missing images, or signs that the site is running on a generic template the developer is claiming as custom work. Test the site on your phone to confirm it works well on mobile devices. Look at the page code: a developer who writes carefully will have page code that shows structure and planning, not a chaotic mass of auto-generated tags from a page-builder tool. If a developer cannot show you five live, working websites they built for real paying clients, or if their portfolio consists of mockup screenshots rather than actual deployed sites that are live on the internet, that is a red flag about whether they have the experience they claim.
- Unclear answers about who controls the website's underlying technology after handoff. Three questions every web developer should answer clearly before a project starts: What tools and platforms will be used to build this? Will I own and control all the code and files that make up my site? If I need to switch to a different developer later, how hard is it to move the site to someone else's care? A developer who uses a proprietary drag-and-drop page-builder tool that only works on their hosting company creates a situation where you cannot easily move away if you want to. A developer who builds using WordPress with premium add-ons may saddle you with annual license fees you did not expect. A developer who writes clean, portable code you own outright creates something any competent developer can take over later. These are not equivalent outcomes. A developer who cannot clearly explain whether you will own your site, whether you can move it elsewhere, and what the long-term costs are is not ready to be your partner.
- Pressure to sign before you have reviewed the contract or compared quotes. "This pricing is only available if you sign this week" is a manufactured constraint designed to prevent you from doing due diligence. It is especially common in web development proposals that contain vague scope language, because a client who has not compared the contract against a competitor's quote is less likely to notice that "a professional website" is not the same as a named list of pages and features. The developer's calendar might have constraints, but those constraints exist independently of whether you have had time to read what you are signing or verify the IP assignment clause is in the contract at all. A developer confident in their scope definition, pricing, and contract terms has no reason to prevent you from reviewing them carefully. The urgency benefits them, not you.
- Promises that seem disconnected from reality on price or timeline. A quality multi-page website with custom functionality is not built in three days. A complex site does not cost $1,200 all-in from a developer promising enterprise-level features. When a quoted price or timeline is significantly below what comparable professionals charge, the scope is being understated, corners are being cut on quality, or the developer is underpricing to win the work and intends to make it up through scope disputes, upsells, or cutting things that were implicit but never written down. Ask specifically what is included at that price. Ask what is explicitly not included. Ask how they plan to complete it in that timeframe given other projects they are working on.
- Domain or hosting placed in the developer's name, presented as the standard approach. If a developer includes "I'll register the domain and set up hosting for you" in a proposal without specifying that both will be in your name and your accounts, ask directly. If they indicate they generally manage everything in their own account for simplicity or administrative efficiency, decline. If they push back when you ask for it in your name, end the conversation. This is not a matter of preference or convenience. It is about who legally controls your business identity on the internet.
- Contract language that transfers liability to you for their choices. Read the indemnification clause carefully. If it requires you to indemnify the developer against any and all third-party claims arising from the work they deliver, you are accepting liability for their decisions about what to include in your site. If they used a stock photo that turned out to be improperly licensed, that is their problem, not yours, under a fair indemnification structure. Push back on one-sided indemnification language before signing. Read the full guide on choosing a web developer →
Key takeaways
- The contract must include an explicit IP assignment clause stating copyright transfers to you on final payment. The legal default without it is that the developer retains ownership,even after you have paid in full.
- A work-for-hire clause alone is not enough. Include a backup IP assignment clause so ownership transfers even if a court finds the work-for-hire doctrine does not apply to a specific element.
- Your domain registration must be in your name, in your account. Developer-managed DNS is fine. Developer-owned domain registration is not, under any circumstances.
- Scope should be specific enough that a neutral third party could determine whether it was fulfilled,named pages, named features, revision rounds, content responsibilities, and the technology platform.
- The contract needs a change-order process: any out-of-scope work must be documented and approved in writing, with a specified rate, before work begins.
- Payment should track progress. A deposit at signing, a milestone payment on staging delivery, and the balance at launch is the structure that keeps risk balanced for both parties.
- The contract should name specific milestone dates and define what happens when any of them is missed, including the final launch date.
- A 30-90 day post-launch warranty covering bug fixes in the delivered work at no additional charge is a standard and reasonable term. Confirm it is in the contract before signing.
- Read the liability cap and indemnification clause. Confirm both are reciprocal, not structured to protect only the developer.
- Refusing to use a contract, vague answers about technology and ownership, pressure tactics, and domain registration in the developer's name are all disqualifying. None of these improve once money has been paid.
Frequently asked questions about web developer contracts
Should the contract explicitly say I own the code?
Require written final-payment transfer of copyright/IP in code, design assets, and database content. Otherwise developers generally retain copyright, granting licenses that may be revocable, fail on business closure, or prohibit new-developer handoff. Verbal assurances aren't contractual commitments. Request IP assignment specifically, beyond limited independent-contractor work-for-hire language.
Does the work-for-hire doctrine automatically give me ownership of code I commissioned?
Not automatically. US work-for-hire covers employees; contractors need explicit terms and qualifying commissioned-work categories. Custom software remains legally ambiguous. Include both work-for-hire and backup IP assignment so ownership transfers even if courts reject the first doctrine.
What if a developer won't use a contract at all?
Treat refusal as disqualifying. Contracts protect both parties by defining deliverables, cost, timing, and ownership. Oral arrangements leave no recourse for delays, narrowed scope, or disputed promises. Resistance indicates inexperience or deliberate flexibility to change terms, unsuitable for business-critical infrastructure.
Who should own the domain name?
Always register in your own registrar account/name, with your administrative/technical contacts. Developer DNS management is normal; developer registration creates indefinite dependence. Price increases, disappearance, or relationship breakdown threaten domain/email access, with slow, uncertain recovery. Require ownership before work starts.
How should change orders work when I want something added mid-project?
Out-of-scope requests require written work/cost/timeline orders approved before changes, billing, or work; email usually suffices. This prevents surprise invoices and unpaid creep. Include the applicable rate contractually before signing. Changes are virtually inevitable on projects longer than a few weeks.
Is a 50% deposit upfront normal?
Yes. Standard 25-50% deposits fund planning/kickoff and commit both parties. Paying 75-100% before work, or final balances before seeing completion, sacrifices leverage. Balance risk with signing deposit, approved-staging payment, and launch balance after review.
What happens if the developer misses the deadline?
Contracts govern remedies. Specify milestones, a grace period (such as 30 days without written extension), and options: agreed new date, partial delay refund, or termination/prorated refund for undelivered work. Bare dates lack enforceable consequences. Though not standard, accountability terms are reasonable; resistance reveals schedule-pressure habits.
What should post-launch support look like in a contract?
Specify 30–90 days of free defect repair in the agreed environment, distinguishing bugs from paid features. Afterward define retainers, hourly/project rates, and urgent response expectations. Undefined support is especially costly to discover during a Friday-evening breakdown.
Does the contract need a liability or indemnification clause?
Yes. Fee-level liability caps are widely accepted; consequential losses, revenue, business, outage effects, are nearly always excluded. Challenge one-way indemnification. For developer-selected libraries, fonts, photos, or APIs, specify licensing responsibility. You shouldn't absorb third-party IP claims caused by their choices.
How specific does the scope section need to be?
Define pages, features, functionality, platform, revision rounds/boundaries, and copy/image/logo responsibility so neutral reviewers can assess delivery. Vague brand-quality promises and unwritten kickoff assumptions diverge under pressure, especially without written change orders.