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.
By default in the United States, whoever creates something owns it. If a developer writes code for your project, that developer owns the code unless the contract explicitly says otherwise. This is true even if you pay in full. The payment buys you the right to use the work, but not necessarily the right to own it, give it to someone else, or change it without permission. There is a legal concept called "work for hire" that can transfer ownership to you, but it only applies automatically to employees, not freelancers or agencies you contract with. For a freelancer or agency, you need explicit contract language stating the work is "for hire" and transfers to you, and even then the law is unclear. The safest approach: the contract should include clear language stating that you own everything built for the project after final payment, plus a backup clause that transfers ownership to you if the "work for hire" language does not hold up in court. This double protection ensures that no matter what a judge later decides, you end up owning what you paid for.
Why does this matter practically? If you want to switch to a different developer three years from now, you need to be able to hand them the code without the original developer's permission. If the original developer has gone out of business, changed careers, or is simply unresponsive, a license arrangement may not give you the legal right to take the code somewhere else. If there is a dispute about the work, a developer who retained copyright has leverage over your ability to continue using the site. If you want to sell your business, the buyer's due diligence will ask who owns your website code, and "we just have permission to use it" is a much weaker answer than "we own it outright."
The contract language you want to see is a clear statement that upon receipt of final payment, you own everything: the website code, design files, graphics, the database that stores your data, and any custom software written for the project. The developer can retain the right to show the project in their portfolio as an example of their work, which is standard and reasonable. But you own everything else. If the developer uses off-the-shelf software components or libraries (like open-source code), the contract should clarify which parts fall under those other licenses versus what was built specifically for you (which is yours).
One often-overlooked clause related to ownership: confidentiality. If your site involves proprietary business logic, pricing models, client intake processes, or anything you would not want a competitor to see, the contract should include a confidentiality clause covering what the developer has access to during the project. Most professional contracts include this as standard language, but confirm it is there and that it does not expire unreasonably quickly after the project ends. A clause that terminates at project completion protects nothing if you later discover the developer shared details about your system with another client building a competing service.
Domain and hosting ownership
Code ownership is the most legally complex issue in a developer contract, but domain ownership is the one that causes the most immediate practical problems when it goes wrong. Clients lose control of their domain more often than you would expect, and it is almost always because of an assumption made at the start of the project that was never written down.
The domain should be registered under your name, with your email address, in your registrar account. Not your developer's account, not the agency's account, and not an account controlled by a third-party reseller you have never heard of. The domain is your property. It is tied to your brand, your email addresses, and your identity on the internet. If you lose access to it, every email address at that domain stops working, your website goes dark, and recovering the domain from a registrar when you cannot prove ownership of the registrant account is a slow, painful process with an uncertain outcome. Domain recovery through ICANN's dispute resolution process takes months and costs money even when you win.
It is acceptable for a developer to manage the domain's technical settings on your behalf, meaning they help configure where your domain points on the internet. It is also acceptable for a developer to host your site on their own servers. What is not acceptable is for the developer to register the domain itself in their own name or account. If a developer is handling domain registration and does not explicitly offer to register it in your name, ask directly. If they push back or claim that it is "easier" to manage everything under their single account, that is a serious warning sign about how they think about client ownership more broadly.
Your hosting account deserves the same attention. Understand who has the login credentials for your hosting account, where your site's backups are stored, and what happens to all your site's files if you stop working with that developer. The contract should make this explicit: if the relationship ends for any reason, the developer must provide you with a complete copy of everything—your site files, all your data, everything—within a defined time period, typically five to ten business days. An exit clause that covers this handoff is not a sign you distrust the developer; it is a sign that both parties have thought through what a professional parting looks like rather than leaving it as an uncomfortable conversation for when the relationship is already strained.
A few related questions worth answering in writing before work starts: Who controls the technical settings that point your domain to the internet? Who manages your site's security certificate (the lock icon in the browser), and who is responsible for renewing it each year? If the developer uses a hosting reseller account (a middle-person arrangement), what happens to your site if the developer's account is suspended or shut down for any reason? These scenarios happen, and having the answers in writing is the difference between a manageable transition and an emergency where your site is down, your email is not working, and you have no idea who controls the servers your business runs on.
Scope definition: what you are buying
Scope disputes are the most common source of conflict in web development projects, and they almost always trace back to a contract that used general language where specific language was needed. "A professional website for your business" is not a scope definition. It is an aspiration. When the client expected ten pages and the developer delivered four, or the client expected a contact form with email notifications and the developer quoted it as an additional cost, or the client asked for a revision and the developer treated it as new work billed at an hourly rate. The root cause is almost always the same: insufficient scope definition in the original contract.
Good scope definition in a web development contract lists the specific pages being built and their purpose. Not "several pages" but an actual numbered list: Home, About, Services overview, three service detail pages, Contact, Privacy Policy. It specifies what features will work: a contact form that sends you emails, a map, a photo gallery, a layout that works on phones and tablets, basic search engine setup. It specifies how the site will be built: pure custom code, WordPress with a particular theme, or a drag-and-drop page builder. It covers external systems: if the site needs to connect to a scheduling system, a payment processor, or a customer database, those connections should be explicitly included in scope or explicitly excluded, with a note about how they would be added later and at what cost. "We can add that later" is not sufficient when your business depends on scheduling being ready at launch.
Revisions are where scope gets fuzzy most often. The contract should define how many rounds of revisions are included and what "one round" means. Typically: one batch of feedback per section, not unlimited small changes trickling in over weeks. The contract should also define what counts as a small revision versus a new request. A revision is fixing copy or changing a button color. A new request is adding a service not in the original scope, restructuring the navigation after it was approved, or adding features that were never discussed. If this distinction is not written down, every time you ask for something, the developer negotiates whether you have to pay extra or whether it is already included.
One specific scope issue worth addressing in writing before work begins: content responsibility. Who is writing the copy on each page? Who provides the images? If the developer is not writing copy or sourcing photography, the contract should say so explicitly, and it should specify what happens if client-provided content is delayed. Many projects run late not because the developer is slow but because the client took three weeks to produce their About page copy. The contract should establish a content deadline and define what happens if it is missed. Either the timeline adjusts proportionally, or the developer proceeds with placeholder content that gets swapped in later, or the client pays an additional fee for the delay. Any of those is a fair outcome. Having no answer is not.
Change orders and out-of-scope requests
Scope definition tells you what the project includes at the price you agreed on. Change orders are the process for handling everything that falls outside that scope. These are separate concepts that both need to be addressed in the contract, and the change-order process is one most clients do not think to ask about until they are already in a dispute about it.
The change-order process should work like this: a client requests something that is not in the original scope, or the client and developer agree something needs to change from what was originally planned. Before any additional work begins, the developer produces a written change order describing what the additional work is, what it costs, and how it affects the project timeline. The client approves the change order in writing (an email confirmation is sufficient), and then the developer proceeds. No work, no billing, no timeline impact takes effect without that written approval. This process protects both parties: the client knows exactly what they are agreeing to pay before it appears on an invoice, and the developer has documented authorization for every dollar of additional work.
What happens without a formal change-order process is predictable. Developers absorb small requests without documenting them, the cumulative effect is significant unpaid work, and at the end of the project the developer is resentful and the client is confused about why the relationship feels strained. Alternatively, developers bill for additional work after the fact without prior agreement, and clients feel blindsided by invoice line items they never approved. Both scenarios are avoidable with a one-paragraph change-order clause in the original contract.
The contract should also specify the rate that applies to out-of-scope work. This might be a flat rate per change order, an hourly rate, or a day rate. Whatever it is, having the rate agreed in advance means that when you request something outside scope, the conversation is "that's two hours at $X, should I proceed?" rather than a negotiation over what the work should cost after it is already done. Ask for this clause specifically if the developer's contract template does not include it. A professional developer will have a standard rate for out-of-scope work and will not object to naming it in the contract.
Payment structure and milestone payments
How a web development contract structures payment affects your risk exposure if things go wrong, and it signals something about how the developer thinks about the working relationship. A payment structure that puts most of the financial risk on one party (either paying almost everything upfront before work starts or making the developer wait until launch for most of their compensation) creates incentives for problems that a better structure would avoid entirely.
The standard approach is a deposit at signing followed by milestone-based payments. A typical structure for a project in the $2,800–$5,000 range might be 30-50% at contract signing to begin work, a second payment when a staging version of the site is delivered for review and approved, and the balance at launch after the client approves the final product. Some developers use a three or four-payment structure for larger projects, adding a milestone at completion of design mockups or at the end of development before testing. The specific split matters less than the underlying principle: payment should track progress, so you are never significantly out of pocket ahead of what has been delivered.
Be wary of any contract that asks for more than 50% upfront before work begins. A modest deposit is reasonable and signals mutual commitment. But a requirement for 75% or 100% upfront transfers most of the project risk to you. If the developer delivers something that does not match what was promised, delivers it months late, or delivers nothing at all, you have very little leverage when most of your money is already paid. Conversely, be cautious of any structure where almost nothing is due until launch. A developer who cannot require a deposit may not have the financial stability to sustain the project through completion, and that instability can show up as delays, disappearing communication, or corners cut to finish quickly.
The contract should also specify what happens to payments if the project is cancelled or stopped before completion. If you stop the project after the developer has completed significant work, is the deposit fully kept? Is it divided based on what has been delivered? If the developer stops or fails to finish, what part of money already paid is refunded? These are uncomfortable questions at the start of a project, but they are much less uncomfortable than navigating a dispute later with no written answer to fall back on. A professional developer who has done this work for years has handled project cancellations before and will have standard language for it.
Finally, confirm what payment methods the developer accepts and whether there are any extra fees. Many developers charge an extra fee for credit card payments, typically 2.9-3.5%. If you prefer to pay by bank transfer to avoid this, ask before signing. If you do pay by credit card, ask your card issuer whether they will let you dispute a charge if the developer has delivered some work but not finished the project. The answer varies by card company and situation.
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.
A contract should name specific dates or timeframes for each checkpoint, not just the final launch date. A kickoff date, a date when design mockups are ready, a date when a test version is ready to review, a date when revisions are finished, and a target launch date. For each checkpoint, the contract should specify what counts as approval from you, because projects frequently stall at review points when you are slow to respond, give vague feedback, or keep changing your mind. Both parties need defined obligations: the developer delivers by a date, and the client responds by a date.
When evaluating the proposed timeline, ask the developer to explain how they arrived at it. A realistic estimate accounts for design iteration, revision cycles, client content delivery delays, and testing time. A developer who proposes a two-week timeline for a multi-page site with custom functionality is either very experienced with exactly that scope of project, or underestimating. Ask which it is. Ask what similar projects they have built recently and how long those took. Ask what the most common reason their projects run past the originally quoted date. A developer who deflects these questions or gives vague answers is telling you something about how they handle accountability.
The contract should address what happens when a milestone is missed. Most contracts name a final launch date and say nothing about what happens if it is not met, which gives you essentially nothing to enforce. A better approach includes a grace period definition: a milestone is considered breached if it is more than a specified number of days past the agreed date without written extension, and a remediation menu: a written extension with a new date, a partial refund for delay, or the right to terminate the contract and receive a pro-rated refund for work not yet delivered. These clauses are not standard in most developer contracts, but they are not unusual either. If they are absent and timeline matters to your business, ask for them before signing.
Post-launch support and warranty terms
A web development contract that ends at launch is incomplete. Websites break after launch in ways that were invisible during testing. A contact form stops delivering emails because of a server configuration change. A third-party booking integration breaks after an API update. A browser update causes a layout issue that was not visible in pre-launch testing. The question is not whether something will need attention after launch, but whether the contract defines who handles it and at what cost.
Look for a warranty period, typically 30 to 90 days after launch, during which the developer fixes any broken features at no extra cost. A broken feature is something that was supposed to work in your hosting environment and does not. The warranty covers what the developer delivered in the agreed-upon hosting setup, not a guarantee that the site will work correctly no matter what you do to it after launch. If you add extra plugins or tools, directly edit the code yourself, or switch hosting providers in a way that breaks something, that is not a warranty claim.
The contract must draw a clear line between warranty work and new feature requests. This distinction is difficult to navigate in practice, which is exactly why it needs to be in writing. A form that never submitted email was always supposed to submit email: that is a bug. A request to add a new field to the form after launch is a new feature. A layout that breaks on a newly released device model is arguably a bug if the original contract specified responsive design, and arguably a new feature if it is a device category that did not exist when the site was built. Having a defined process for categorizing post-launch requests, and a defined rate for out-of-warranty work, prevents these gray areas from becoming disputes.
Outside the warranty window, the contract should define ongoing support. Some developers offer a monthly retainer where you pay a fixed amount each month for a certain number of support hours. Others bill by the hour for extra work after the warranty ends. The contract should state what this costs, or at minimum confirm that a rate exists. If the developer is not offering ongoing support, the contract should say so clearly so you can plan ahead (either by hiring someone else later or by making sure you have all the files and instructions needed for another developer to take over).
Two specific post-launch considerations that belong in the contract: software updates and data backups. If the site runs on WordPress or another platform that needs regular security updates and add-on updates, who is responsible for applying those updates after launch? If the developer is hosting the site, what is the process for requesting a complete copy of your data or a full backup of all the site files? Answers to both of these should be in writing before launch, not improvised after the relationship has already ended.
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 limit the maximum amount the developer is responsible for if something goes wrong as a result of their work. Most professional developer contracts cap liability at the amount you paid for the project. This is a reasonable and widely accepted position. If a website bug causes you to lose a significant customer or a day of business, a developer is generally not in a position to make you whole for that consequential loss, and courts in most jurisdictions recognize the enforceability of these caps. What you want to confirm is that the cap is reciprocal. If the liability cap applies only to the developer's exposure but not to yours — meaning you could be held responsible for unlimited damages arising from something you did with the site after delivery — that is an asymmetric agreement worth pushing back on.
Ownership protection for third-party components specifies who bears responsibility if someone later claims the developer used copyrighted or trademarked content without permission in your site. This happens when developers use stock photos, icon libraries, code libraries, fonts, or website templates. If the developer includes components that were not properly licensed for commercial use, and the rights holder later makes a claim, this clause determines whether you are responsible for paying legal fees and damages or the developer is. A professional developer should promise to protect you against third-party copyright or trademark claims arising from materials they included in your site. If the clause instead says you are responsible for defending the developer against such claims, read that very carefully before signing. That puts you on the hook for the developer's mistakes.
Dispute resolution language specifies what happens if the parties cannot agree. Options include talking it out directly, using a neutral mediator, going to binding arbitration (a private judge), or going to court. Arbitration clauses are common in developer contracts. Arbitration is faster and cheaper than court, but it prevents you from taking the dispute to small claims court, which is often the simplest and most practical option for disputes in the $1,200 to $5,000 range.
Also note which state's laws will apply. The contract specifies which state's law governs the agreement and where any dispute would be heard. If you are in Florida and the developer is in another state, and the contract says disputes are handled under the developer's state's law, it means you would be dealing with that state's legal system if something goes wrong. This is not a deal-breaker, but ask for your state's law to apply when you can. Most developers will agree, because they want local jurisdiction for their own protection too.
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 genuinely 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.
Terms that are less flexible but worth raising: the clause that transfers code ownership to you (if it is missing, ask for it — do not accept a refusal), the requirement that your domain is in your name (non-negotiable — it is either yours or you walk), and whether the liability cap is fair to both of you or just the developer. A developer who refuses to add a clause transferring code ownership to you is telling you they want to keep owning the code, which means every future change, every future developer you hire, and any future sale of your business gets complicated by that decision. That is not acceptable when you are paying for custom-built work.
How to raise contract issues without damaging the relationship before it starts: be direct and specific. Do not hedge with apologies about being difficult. Say "I want to add a clause assigning IP rights to me on final payment. Can you add that?" or "The payment structure asks for 60% upfront, which is more than I'm comfortable with before any work is delivered. Can we restructure to 40% upfront, 30% at staging, 30% at launch?" Most professional developers have heard these requests before and have standard ways of accommodating them. The ones who react badly to reasonable contract questions are the ones you learn something important about before you have paid them anything.
One practical approach: review the contract on your own first, make a list of the specific parts you want changed or added, and send a written request with your proposed changes. Do not send back a heavily marked-up contract with edits all over it — that signals you are looking for a fight. A targeted request for two or three specific changes is easy to respond to and does not put the developer on the defensive.
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 genuinely 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 typically 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 one is missed,not just when the final launch date slips.
- 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.