A freelance web developer contract should put six things in writing: exactly what is being built, who owns the code and the accounts, the payment stages, how many rounds of revisions are included, the deadlines on both sides, and what gets handed over at the end. Ownership matters most, because in India, the UK and the US the developer owns the code by default until a signed document says otherwise. Two or three clear pages agreed before work starts settle those questions while everyone is still on good terms.
I'm a freelance developer in Gurugram with clients in India, the UK and the US, so I sit on the other side of this document. This is the version I'd want you to have as the buyer.
General advice, not legal advice
I'm a developer, not a lawyer. Use this as a checklist of what to agree, then have a lawyer in your country review the wording if the project is large or the stakes are high.
What should a freelance web developer contract include?
A freelance web developer contract should cover scope, ownership, payment, revisions, deadlines, acceptance, handover and how either side can end it. Everything else is detail on top of those eight.
Most templates online are written by freelancers, for freelancers. They protect the developer from late payment and endless changes, which is fair, but they say very little about the things that hurt a client: not owning the code, not holding the logins, and paying the final invoice before the site has been checked. Read any template with that in mind.
Here is the short version of each clause and what goes wrong when it's missing.
| Clause | What it should say | What goes wrong without it |
|---|---|---|
| Scope | The pages, features and integrations being built, plus a list of what is not included | "I thought that was included" arguments in week four |
| Ownership | That copyright in the finished site passes to you, and when | You paid, but the developer still legally owns the code |
| Payment stages | The amount, the trigger for each payment and the due date | You pay most of the money before you've seen anything |
| Revisions | How many rounds, at which stages, and what extra changes cost | Either endless free changes or surprise invoices |
| Deadlines | Dates for the developer and for you, and what happens when either slips | A six-week project that takes five months with nobody at fault on paper |
| Acceptance | How long you have to test, and how bugs are reported and fixed | The site is declared "done" while still broken |
| Handover | Every login, file and account you receive, and by when | A live site you can't move, edit or back up |
| Ending early | Notice period, what is paid, what is delivered | A half-built site and no right to the files |
The contract doesn't have to be one long document. A common and perfectly good setup is a proposal or scope document for the project details, plus a page or two of standard terms, both signed.
Is a web development contract the same as a website development agreement?
Yes. A web development contract, a website development agreement, a freelance contract and a statement of work all describe the same thing: a signed document that says what will be built, for how much, by when, and who owns it. The name on the cover changes nothing.
What matters is that it is written down and both sides have signed or clearly accepted it. A chain of WhatsApp messages and a paid invoice can amount to an agreement, but it won't answer the hard questions. It certainly won't transfer ownership of the code, which needs a signed document in all three countries I work with (more on that below).
You'll usually see one of three formats:
- A single agreement. Everything in one document. Good for larger builds.
- Terms plus a scope document. Standard terms that stay the same, and a separate scope, price and timeline for this project. Good if you expect more work with the same developer later.
- A signed proposal. The proposal itself contains the terms. Fine for small jobs, as long as ownership, payment and handover are actually in it.
If a developer says "we don't need a contract, I'm easy to work with", treat that as a reason to insist. People who are easy to work with don't mind writing down what they've promised.
Do you legally need a written contract with a freelance developer?
In most places a verbal deal is still a valid contract, but some laws now require a written one, and you need writing anyway to own the code. So in practice, yes.
Two examples from the US, both taken from a summary by the law firm Nixon Peabody. New York State's Freelance Isn't Free Act requires a written contract once the work passes an $800 threshold, counted on one contract or added up over the previous 120 days. The contract has to list the services, the fee and the payment date, and if no date is set, payment is due within 30 days of the work being completed. A business that skips the written contract can face $250 in statutory damages. California's Freelance Worker Protection Act, which applies from January 1, 2025, sets a similar written-contract rule with a $250 threshold, according to the same summary.
India and the UK don't have a direct equivalent for website projects, but both have late payment rules that apply whether you write them down or not. I cover those in the payment section.
The practical reason is simpler than any statute. A website project runs for weeks, involves dozens of small decisions, and both people remember them differently by the end. The written version is the only one that doesn't change.
Who owns the website and the code once it's built?
The developer does, unless the contract says the ownership passes to you. Paying the invoice does not transfer copyright on its own in India, the UK or the US.
This surprises a lot of business owners. Here is what the default looks like in each country.
| Country | Default rule when you hire a freelancer | What changes it |
|---|---|---|
| UK | The UK government's guidance says the first owner of copyright is the person who created the work, not the commissioner, unless you agree otherwise in writing. Without a clause, you may only get a limited licence to use the work | A written agreement that assigns the copyright to you |
| US | Copyright "vests initially in the author" of the work, which for a freelancer's code is the freelancer | A transfer is not valid unless it is in writing and signed by the person giving up the rights |
| India | Section 17 of the Copyright Act says the author of a work is the first owner of the copyright. A founders' guide that quotes the Indian law firm Khurana & Khurana reads that as freelancers and contractors keep the copyright unless a written assignment says otherwise, and payment alone does not transfer it | Section 19 says an assignment is not valid unless it is in writing and signed by the person giving up the rights. It also has to identify the work, the rights, the duration and the territory |
One Indian detail is easy to miss. Section 19 of the same Act says that an assignment with no stated period is deemed to last five years, and one with no stated territory is presumed to cover India only. If your developer is in India, ask for the clause to state both the period and the territory in so many words, and have a lawyer check that line.
So the ownership clause is the one part of the contract you can't fix with a friendly phone call later. If the developer has vanished or the relationship has soured, you have nobody to sign the transfer.
What should the ownership clause say?
It should say that all rights in the custom work created for your project pass to you once you've paid in full. Tying the transfer to final payment is normal and fair to both sides: the developer is protected until they're paid, and you own everything the moment you've paid.
Ask for these points in plain words:
- Custom work is assigned to you. Design files, custom code, custom plugins or themes, and the content they wrote for you.
- The developer's reusable code is licensed to you. Most developers have starter code and helper functions they use on every project. They won't give up ownership of those, and they shouldn't have to. You need a permanent, free right to use and change them as part of your site.
- Third-party items are listed. Themes, plugins, fonts, stock photos and paid services each come with their own licence. The contract should name the paid ones and say who buys them.
- Portfolio use is agreed. Whether the developer can show your site in their portfolio, and whether anything must stay confidential.
On paid plugins and themes, I agree with the plugin makers at Delicious Brains: "If a paid plugin is integral to the site, the client should be the owner of the plugin license." If the developer buys it on their own account and later stops renewing, you lose updates and support for something your site depends on. Have the licence bought in your name, with your email and your card.
Should the accounts be in your name too?
Yes. Owning the copyright is useless if you can't reach the files. The domain name, the hosting account, the code repository (the online folder where the code and its history are stored) and any payment or analytics accounts should be registered to your business, with the developer added as a user. Not the other way round.
Write that into the contract as a simple line: "All accounts are created in the client's name and paid for by the client. The developer is given access for the length of the project." It takes ten minutes at the start and saves weeks at the end. I've written a full guide on what to do if it's already too late: how to take back your WordPress site when a developer disappears.
What freelance developer payment terms are normal?
Normal freelance developer payment terms are a deposit before work starts, one or two payments tied to stages you can see, and a final payment at or just before launch. Paying everything up front is not normal, and neither is paying nothing until the end.
Contra's guide to payment schedules says most web designers ask for between 25% and 50% of the project cost upfront. Smaller projects (the guide uses under $5,000) typically see a 50% deposit, and larger ones start with 25% to 33% down. The UK freelancer body IPSE suggests a three or four stage milestone invoicing system: a deposit, a payment when the designs or first draft are presented, and a payment on final delivery such as the website launch.
The Freelancers Union gives a worked example I like because of how it ends. It splits a project into a 50% deposit, two milestones of 12.5% each, 15% on the final deliverable and 10% on asset transfer.
- Deposit50%
- Milestone 112.5%
- Milestone 212.5%
- Final deliverable15%
- Asset transfer10%
That last slice is the useful idea for a buyer. A payment tied to asset transfer means some money stays unpaid until the logins, files and accounts are in your hands.
Which payment structure suits which project?
Pick the structure by the size and length of the project. Short jobs don't need four invoices, and long jobs shouldn't have just two.
| Project | Structure that fits | Why |
|---|---|---|
| Small fix or a one-page site | Half before, half on completion | Milestones add admin for no benefit |
| A typical business website | Deposit, a payment on design approval, a payment at launch | Each payment follows something you've seen and approved |
| A store, booking system or web app | A smaller deposit, then three or four stage payments, with the last one on handover | Spreads the risk evenly across a long build |
| Ongoing work with no fixed end | Monthly, or hourly billed weekly or fortnightly | There's no "finished" to tie a payment to |
Whatever the split, tie each payment to something you can check. "Design approved" and "site working on a test link" are checkable. "50% of development complete" is not, because nobody can measure it.
What else belongs in the payment clause?
The payment clause should also state the due date, the method, the taxes, and what happens when a payment is late. These are small lines that prevent long email threads.
- Due date. How many days you have to pay each invoice, counted from the invoice date.
- Tax. Whether the price includes GST in India, VAT in the UK, or neither. A quote that turns out to be "plus tax" is a nasty surprise.
- Currency and fees. If you're in the UK or the US and your developer is in India, agree the currency and who pays bank or transfer charges.
- Expenses. Hosting, domains, paid plugins and stock photos. Ideally you pay these directly on your own card, so they're in your name.
- Late payment. Contra's guide says standard late fees run about 1.5% per month on overdue balances. Many contracts also let the developer pause work until an overdue stage is paid. Both are reasonable.
Be aware that the law may set late payment terms even when your contract is silent:
- UK. If no date is agreed, a payment is late 30 days after you get the invoice or the work is delivered, whichever is later. The supplier can then charge statutory interest of 8% plus the Bank of England base rate.
- India. This one only applies if your developer is registered as a micro or small enterprise (an Udyam registration), so ask. Where it does apply, the legal site iPleaders explains that the agreed payment date can never fall more than 45 days after acceptance, and with no agreed date the limit is fifteen days. Interest on late payment then runs at three times the Reserve Bank of India's bank rate, compounded monthly, whatever your contract says.
- New York. With no date in the contract, payment is due within 30 days of the work being completed.
None of this should worry a client who pays on time. It's just better to know the rules exist before you write "payment within 90 days" into a contract.
How should the scope of work be written?
The scope should be specific enough that a stranger could read it and tell whether the finished site matches. "A modern, professional website" is not a scope. A list of pages, features and exclusions is.
A scope that works for a business owner covers:
- Pages and templates. Name them. "Home, About, Services (one template, six pages), Blog, Contact."
- Features. Contact form and where the entries go, booking, payments, search, login areas, languages.
- Integrations. The other systems the site connects to: payment provider, CRM (your customer database), email tool, analytics.
- Design. Who designs it, in what tool, and whether mobile layouts are designed or left to the developer's judgment.
- Content. Who writes the text, supplies the photos and loads them into the site. This is the single most underestimated job on a website project.
- Standards. Which browsers and devices it must work on, a target for loading speed, basic on-page SEO, and accessibility if it matters in your market.
- Exclusions. What is not included. The Elementor team's contract guide lists the usual suspects: keyword research, writing page titles and descriptions, proofreading the client's text, and design changes after the mockups are approved.
The exclusions list feels negative, but it protects you as much as the developer. If SEO setup or content loading is excluded, you find out before you sign and can add it, instead of discovering the gap a week before launch.
If you don't have a scope yet, write one before you ask for quotes. My guide on how to write a project scope or PRD for a website walks through it, and the free Project Scope Generator will turn a two-line idea into a first draft you can edit.
How many revisions should the contract allow?
Two to three rounds at each design stage is the usual number. Contra's guide says most contracts include 2-3 rounds of revisions per milestone.
The number matters less than the definitions around it. Three things need to be written down.
What counts as one round. A round is one collected set of feedback, sent together, from everyone on your side who has a say. Five emails over five days from three different people is not one round. The Elementor guide makes the same point: send all revisions in one message, not piece by piece.
Where revisions happen. Changes are cheap on a design mockup and expensive once the page is built. A good contract gives you revision rounds on the designs, then a separate round of fixes on the built site. Changing an approved design after the build has started is new work.
What happens after the included rounds. Extra rounds are charged at a stated hourly or daily rate. Ask for that rate to be in the contract now, so you know the price before you need it.
Then there's the change request, which is different from a revision. A revision adjusts something in the scope ("make the heading larger"). A change request adds something that wasn't ("can we add a members' area?"). The contract should say that any change request gets a short written note with the extra cost and the extra time, and that work starts only after you approve it in writing. An email reply saying "approved" is enough. This one habit heads off a lot of billing arguments.
How do you put deadlines in writing when both sides can cause delay?
Write dates for both sides, and say what happens when either one slips. A deadline that only binds the developer isn't realistic, because a website can't be finished without your content, feedback and logins.
A workable deadlines clause has four parts.
- A timeline with stages. Design by this date, test version by this date, launch by this date. Calendar dates are better than "four weeks after kickoff", because nobody agrees later on when kickoff was.
- Your deadlines. When you'll deliver text, photos, logins and brand files, and how fast you'll respond to things sent for review. Sprintlaw's guide to client delay clauses uses five business days as an example response window, and the Elementor guide gives clients 7 to 14 business days to approve design mockups.
- What a delay on your side does. The fair rule is that the developer's dates move by at least as long as you were late. Sprintlaw suggests the clause cover the trigger, the notice, the time extension and any cost impact, and that charges be reasonable and tied to actual costs.
- What a delay on the developer's side does. This is the part freelancer-written templates leave out. Ask for a line that says if the developer misses a stage date by more than an agreed number of days for reasons that aren't yours, you can end the contract, keep the work you've paid for, and receive the files.
Some contracts also include "deemed approval": if you don't respond within the review window, the work counts as approved. That's reasonable if the window is long enough for a busy owner, so check the number and ask for a reminder before it kicks in. Others add a restart fee for projects that go quiet for weeks. Again fair, as long as the trigger is clearly stated.
What should acceptance testing and the bug-fix period look like?
You should get a set number of days to test the site before the final payment, and a period after launch when bugs are fixed for free. Both need a number of days attached.
Acceptance is the step where you check the built site against the scope. The contract should say how long you have, how you report problems (one list, not scattered messages), and that the developer fixes anything that doesn't match the scope before the site is treated as finished. An older but still useful checklist from the law firm Pinsent Masons asks the right questions: who tests, who decides whether the tests passed, and whether acceptance is linked to payment.
The warranty period covers bugs found after launch. Paper Leaf, a development studio, says the industry standard for software warranty periods is 30 days, with 45 or 60 days possible, and explains that longer guarantees raise the price because the developer is taking on more risk.
Define "bug" in one line so the period is useful. A bug is the site not doing what the scope says it should. A new feature, a design change, or a problem caused by someone on your side installing a plugin is not a bug. Start the warranty from a written date, such as the day you confirm acceptance by email.
After the warranty ends, a website still needs updates, backups and security checks. That's a separate arrangement, and it's better to discuss it before launch than after something breaks.
The IPL Biologicals store is an example of that split. I did the main build of their WooCommerce store from September to December 2023 and maintained it until April 2024. Since 2025 I have looked after it on a monthly maintenance retainer, which covers new pages such as Grow Organic, catalogue and price updates, and store operations support. The build was one piece of work and the upkeep is another, and your contract should treat them the same way.
What should the handover clause cover?
The handover clause should list every item you receive at the end and give a date for it. "Full handover on completion" is too vague to enforce.
- 1
Domain and DNS
The domain is registered in your business name, on your account, with your email as the contact. DNS is the setting that points your domain to your website and email.
- 2
Hosting
The hosting account is yours, paid on your card. The developer's access is removed or reduced once the project ends.
- 3
Admin logins
A full administrator login for the website, plus every connected account: payments, forms, email, analytics, maps.
- 4
Code and design files
The code repository is transferred to your account, and you receive the original design files, fonts and images.
- 5
Licences
A list of every paid theme, plugin and service, who holds each licence, what it costs to renew and when.
- 6
A backup and a short guide
A full backup of the finished site, and a short written or video guide to the tasks you'll do yourself, like editing a page or adding a product.
Two details make this clause work. First, link it to the final payment, in either direction: a small last payment due on handover, or handover within a set number of days of the final payment clearing. Second, say what happens to the developer's access afterwards. If they're maintaining the site, they keep a login. If not, it's removed.
What happens if you or the developer want to stop halfway?
The contract should let either side end it with written notice, and say exactly what is paid and what is delivered when that happens. Projects do stop: budgets change, businesses pivot, and sometimes two people just don't work well together.
Arc's guide to freelance developer contracts uses 30 days as an example of reasonable notice for ongoing arrangements. For a fixed project of a few weeks, shorter notice makes more sense. The clause should then answer three questions:
- What do you pay? Normally for the work completed up to the notice date. Some contracts add a "kill fee", a fixed sum or percentage that compensates the developer for time they'd booked for you. If it's there, check the amount.
- What do you receive? All work completed and paid for, in a usable form, including files and logins. Without this line, you can pay for half a site and receive nothing.
- What if one side has broken the contract? A notice and a chance to fix the problem first. The Elementor guide's own contract gives the accused party 30 days to address an alleged breach.
What other clauses are worth a few lines?
A handful of shorter clauses round out a website development agreement. None needs more than a sentence or two in plain words.
- Confidentiality. The developer keeps your business information, customer data and logins private, during and after the project.
- Data protection. If the site collects customer details, say who is responsible for what under the privacy law that applies to you.
- Your content. You confirm that you have the right to use the text, photos and logos you supply. This is standard, and it's why you shouldn't hand over images pulled from Google.
- Subcontracting. Whether the developer can bring in other people, and that they stay responsible for the work. I bring in design or app partners on some projects and remain the single point of contact. Your contract should say the same about whoever you hire.
- Liability cap. Most developers limit their liability to a stated sum, often the fees paid under the contract. The Pinsent Masons checklist treats a stated cap as the normal approach. Check it's there and that the number is reasonable.
- Which country's law applies. If you're in London or New York and your developer is in India, the contract should name one country's law and courts. Chasing a small dispute across borders is rarely worth it for either side, which is one more reason staged payments and staged delivery matter more than any penalty clause.
What are the red flags in a contract a developer sends you?
The red flags are the clauses that leave you without ownership, access or a way out. Read for these before you sign.
- No ownership clause, or one that says the developer keeps all rights and "licenses" the site to you. You'd be renting your own website.
- Everything paid up front. A deposit is normal. Full payment before any work is not.
- Hosting or the domain in the developer's name "for convenience". It's convenient until you want to leave.
- "Unlimited revisions". It sounds generous. In practice it means the scope is undefined, and the project either drags or the promise quietly disappears.
- No dates at all, or dates only for your payments.
- No list of what's handed over.
- A proprietary system. If the site is built on the developer's own private platform that nobody else can work on, you can never switch developer without rebuilding. Ask what the site is built with and whether another developer could take it over.
- Reluctance to sign anything. The biggest one.
A contract with no client-side protections isn't always bad faith. Most freelancers use a template and have never been asked. Ask for the changes. How a developer reacts to a reasonable request before the project starts tells you a lot about how they'll react during it. If you're hiring across borders, my checklist for hiring a freelance web developer in India covers the checks beyond the contract.
How can I help with your website contract and project?
I can't give you legal advice, but I can give you a project where the things in this post are written down before you pay anything. That's how I'd want any project of mine to run.
In practice that means a written scope with the pages, features and exclusions listed, payments tied to stages you can see on a test link, a stated number of revision rounds, dates for both of us, and a handover list. Accounts go in your name. I've handled hosting and DNS moves across Hostinger, GoDaddy and Cloudflare for clients, so if your current site sits on someone else's account, I can help you move it to your own as part of the work. And where a site needs looking after once it's live, I run monthly maintenance retainers, which keeps the "what happens after launch" question out of the build contract.
I work from Gurugram with clients in India, the UK and the US, including white-label builds for a London agency, so I know how much a clear written scope matters when the client is in another time zone. If you already have a contract or a template from your lawyer, send it over and I'll tell you honestly which parts I can work to as written.
What should you do next?
Before you sign anything with any developer, check the document against this list: scope with exclusions, ownership on full payment, staged payments, revision rounds, dates for both sides, a test period, a bug-fix period, a handover list, and a way out.
If a clause is missing, ask for it in one plain sentence. You don't need legal language to write "the client owns all custom work once the final invoice is paid".
If you'd like a project set up this way from the start, tell me what you're building and I'll reply with a written scope and the stages I'd suggest. You can also book a 20-minute call from the same page.
