The Freelance Developer Contract: The 24 Clauses That Decide Who Owns the Code and When You Get Paid

Before writing this we fetched the five pages ranking for "freelance developer contract" and its close variants in July 2026, and read every clause each one ships.

Two of them state the single most important rule in software contracting incorrectly, in opposite directions. A developer talent marketplace tells you that "a freelance developer providing programming services to a client is usually a work-for-hire relationship." A tech publisher, in a feature last updated in 2019, tells you that IP "is transferred to that client upon full payment of the final invoice, unless otherwise agreed."

The first is not permitted by the statute. The second describes a default that does not exist.

Both of those pages rank on page one. If you take either at face value, you will sign something that does not do what you think it does, and neither will your client.

This guide goes clause by clause. It gives you the language ungated on this page, names the law behind each clause, and covers the four things every ranking page omits entirely: open source dependencies inside your deliverable, what "done" means when there is a staging environment and a production environment, what actually has to be handed over at the end, and the three state statutes that now put a written-contract duty on your client.

Nothing here is legal advice. It is a map of the decisions, with primary sources cited so you can check the work.

What the ranking pages actually contain#

We scored the five ranking pages against 24 clauses a developer contract needs, and across all five pages only 14 of 120 possible slots were filled.

We counted a clause as present only if it appears in the operative contract text, not in the marketing copy above it. That distinction matters more than it sounds. One vendor's advice section discusses handover checklists, bug-fix warranties, WCAG compliance, hosting costs, and open source clarification. Its actual downloadable contract contains none of them.

Here is the scoring.

Per page: the best result scored 10 of 24. The next scored 3. Then 1. Two scored zero.

The pattern is not laziness, it is business model. Three of the five are published by SaaS companies whose goal is a signup, not a legal update motion, which is why none of them mentions a statute enacted after 2023. Two are published by developer hiring marketplaces and are written from the client's side of the table even though the search intent is yours.

Who owns your code by default#

Absent a signed written assignment, you own the copyright in code you write as an independent contractor, and paying your invoice does not transfer it.

This is the fact that most of the SERP gets wrong, and it cuts against your client, not you. A client who pays $40,000 for a build and never gets a written assignment has bought a license to use the thing, not ownership of it. That surfaces years later during an acquisition, a due diligence review, or a fight over a rewrite.

Why "work made for hire" cannot cover software#

Section 101 of the Copyright Act creates only two routes to work made for hire. The first is a work prepared by an employee within the scope of employment. You are not an employee.

The second route is a specially ordered or commissioned work, and it only applies if the work falls into one of exactly nine categories: a contribution to a collective work, part of a motion picture or other audiovisual work, a translation, a supplementary work, a compilation, an instructional text, a test, answer material for a test, or an atlas (U.S. Copyright Office, Circular 30).

Software is not on that list.

The Copyright Office's own decision tree is blunt about the consequence. Its question 7 asks whether the work falls into one of the nine categories, and if the answer is no, the answer is "the work is not a work made for hire," regardless of what the paper says.

So a contract that says "all deliverables shall be works made for hire" and stops there is, for a pure software build, a clause that does nothing. It is not merely weak. It fails.

There is a narrow exception worth knowing. If your deliverable is genuinely part of an audiovisual work, say gameplay code shipped inside a game, or if you are one of many contributors assembled into a collective work, a work-for-hire recital may have real effect. Those are edge cases. Assume they do not apply and draft accordingly.

The clause that actually transfers code#

Because work for hire is unreliable here, competent software contracts do two things at once: they recite work made for hire where it might apply, and then they add an express assignment as the fallback that does the real work.

Language that does the job:

To the extent any deliverable qualifies as a "work made for hire" under 17 U.S.C. 101, it shall be deemed such. To the extent any deliverable does not so qualify, Developer hereby irrevocably assigns to Client, effective upon Client's payment in full of all amounts due under this Agreement, all right, title and interest in and to the deliverables, including all copyrights. Developer agrees to execute such further documents as Client may reasonably request to perfect this assignment.

Three details in that paragraph are doing specific work.

1. "Hereby assigns," present tense. A promise to assign later is a promise, enforceable but not self-executing. "Hereby assigns" is the transfer itself. Two of the ranking templates say only that the client "will hold" or "will have exclusive ownership of" the deliverables, which states an outcome without performing the transfer.
2. "Effective upon payment in full." This is your leverage. Until the last invoice clears, the copyright is still yours, which means unpaid deployed code is infringement rather than a billing dispute. It changes the conversation entirely.
3. Further assurances. Assignments sometimes need a document you did not anticipate at signing, especially for a patent filing or an overseas registration. Without this line, you can be chased for a signature years later with no obligation on either side, which is worse for both of you.

Background IP: your reusable code is not theirs#

If you have a component library, a boilerplate, or a deploy script you reuse across clients, a bare assignment clause hands all of it to whoever signs first.

That is not a theoretical risk. "All work product created in connection with this agreement" is broad enough to sweep in the auth scaffold you have been carrying since 2021, because you used it in connection with the project.

Carve it out:

"Background IP" means any code, tools, libraries, frameworks or know-how owned or developed by Developer independently of this Agreement, whether before or after its date. Background IP is excluded from the assignment above. To the extent Background IP is incorporated into a deliverable, Developer grants Client a perpetual, worldwide, non-exclusive, royalty-free, sublicensable licence to use, modify and distribute that Background IP as part of the deliverable.

Note what that gives the client: everything they actually need. They can use the thing, change it, and sell the company that owns it. What they do not get is the right to stop you using your own library on the next project. That trade is easy to explain and almost never contested.

For the broader picture of what you are and are not handing over, see freelance IP rights.

The open source problem nobody's template mentions#

Zero of the five ranking pages contain an open source clause, and three of them ask you to warrant that your deliverable infringes nobody's intellectual property.

Put those two facts together and you have a real, uncapped exposure sitting in the most-downloaded software agreement on the search results page.

Here is the mechanism. Your deliverable pulls in dependencies. Most are permissively licensed: MIT-licensed code can go into proprietary software with essentially no downstream obligation beyond attribution, and Apache 2.0 works similarly while adding an explicit patent grant. Those are fine.

Copyleft licenses are different. Under GPLv3 section 5, if you convey a work based on a GPL-licensed program, you must license the entire work as a whole under the GPL to anyone who receives a copy, carry prominent notices that you modified it and when, and make corresponding source available. That obligation attaches to the whole work, not just the file you touched.

Now imagine your client's proprietary SaaS product contains a GPL-licensed component you pulled in for a date picker. If the deliverable is a derivative work and it gets distributed, the client's product is subject to GPL terms they never agreed to. Meanwhile you signed a flat warranty that the software "will not violate the intellectual property rights of any other party," backed in at least one of these templates by a one-way, uncapped indemnity.

You do not solve this by pretending it away. You solve it with disclosure.

Developer will maintain a schedule of third-party and open source components incorporated into the deliverables, listing each component and its licence, and will deliver that schedule with the final deliverable. Developer will not incorporate any component under a copyleft licence requiring disclosure of Client's proprietary source code without Client's prior written approval. Developer's warranty of non-infringement is limited to components Developer authored, and to Developer's knowledge as to third-party components disclosed in the schedule.

That clause does three things: it makes the dependency list a deliverable, it makes copyleft an approval decision rather than an accident, and it narrows an absolute warranty into a knowledge-qualified one. A modern SBOM from your build tooling satisfies most of the first part with no extra work.

When is it done? Acceptance, staging, and silence#

Nothing in a software contract costs more than an undefined "done," and only one of the five ranking pages contains any acceptance procedure at all.

Acceptance is the trigger for your invoice, the start of your warranty period, and the end of your obligation to keep changing things. If it is not defined, the client defines it by feel, and the feel is usually "once I stop having ideas."

Define it in three parts.

1. Name the environment#

"Delivered" for a web build means deployed to a named staging environment against agreed test data, not deployed to production. Production deployment usually depends on things you do not control: the client's DNS, their compliance sign-off, their marketing calendar. Tying acceptance to production hands your payment date to their internal politics.

If the client wants production deployment inside the scope, make it a separate, separately-invoiced milestone with its own dependency list.

2. Name the criteria#

Acceptance criteria should be checkable by someone who is not you. "Works correctly" is not criteria. "Passes the test cases in Exhibit B on the browsers listed in Exhibit A" is.

Write the browser and device matrix into the exhibit at signing. It is the cheapest scope defence in the document, because "it looks wrong on my mother's iPad" stops being a bug when iPad Safari two versions back was never in the matrix.

3. Name the deadline, and what happens after it#

Client will review each deliverable within ten (10) business days of delivery to the staging environment and will either accept it in writing or provide a single consolidated written list of specific failures against the acceptance criteria. If Client does not respond within that period, the deliverable is deemed accepted and Developer may invoice for it.

Deemed acceptance is the clause that unsticks stalled projects. It converts client silence, which currently costs you money, into progress. And it is not aggressive: ten business days with a written failure list is a generous review window by any standard, which makes it easy to defend when the client's lawyer asks.

Tying invoices to accepted milestones rather than to calendar dates is the whole game here, and milestone billing for freelancers plus invoicing for web developers cover how to split and price them.

Pair it with a change-order mechanism so that anything outside the criteria is priced rather than argued about. One widely-downloaded template on this search actually says the developer "will use its best efforts to implement the requested change at no additional expense to the Client and without delaying delivery." That is unlimited free scope creep, written into the contract, in the most popular software agreement on the page. Strike it every time you see it.

For the scripts that go with this, see scope creep scripts for freelancers and how many revision rounds to put in your contract.

Handover: what actually has to change hands#

A contract that assigns copyright but never lists the artefacts leaves the client owning code they cannot deploy, and it is the most common reason a "finished" project generates unpaid support requests six months later.

Ownership of a copyright is not the same thing as possession of a working system. Write the handover as a numbered deliverable so it is a defined event with a defined end.

Add a completion line: on delivery of these items and payment in full, handover is complete and further support is billable at your stated rate. Without it, "handover" is an open-ended relationship.

The design-side equivalent of this argument, and the reason to price it rather than assume it, is covered in do clients get the source files.

When escrow is worth discussing#

Source code escrow is a three-party arrangement: you deposit the source with a neutral agent, and the client can obtain it if a defined trigger occurs, typically your insolvency or your failure to perform maintenance obligations. Modern escrow agents pull deposits directly from a Git host.

For a solo freelancer on a $15,000 build, escrow is overkill and the agent fees are disproportionate. It becomes a reasonable conversation when you are the sole maintainer of something operationally critical to a client's business and you are keeping the source rather than assigning it, for example a licensed product rather than a bespoke build. If a client raises it on a normal project, the cheaper answer that solves their actual fear is a repository handover on every milestone rather than only at the end.

Warranty, maintenance, and the line between them#

Confusing a warranty period with a maintenance agreement is how developers end up doing a year of free work, and only one ranking page separates them at clause level.

They answer different questions.

A warranty says: for a defined window after acceptance, if the deliverable does not do what the acceptance criteria said it does, I will fix it at no charge. That is a defect remedy, and it should have a hard end date. Thirty, sixty, or ninety days are all defensible choices. Anything without an end date is a permanent obligation you priced once.

Maintenance says: for a recurring fee, I will keep this running, update dependencies, patch security issues, and be reachable. That is a separate agreement with its own scope and its own invoice.

The clause that separates them:

Developer warrants that for thirty (30) days following acceptance the deliverables will conform in all material respects to the acceptance criteria, and will remedy non-conforming defects reported in that period at no charge. This warranty does not cover changes to requirements, changes made by Client or third parties, failures of third-party services, or defects arising from Client's hosting environment. Ongoing maintenance, support and enhancement are outside this Agreement and are available under a separate agreement.

Note the exclusions. Almost every "warranty" support request a freelance developer receives is actually one of those four things, and naming them turns a defensive argument into a quotation.

If you want the recurring-revenue version of the second half, retainer invoicing covers how to structure and bill it.

Third-party costs, and whose card they sit on#

Hosting, domains, SSL, API usage and paid libraries are not part of your fee, and none of the ranking templates say who pays for them.

The default that happens without a clause is that everything lands on your credit card during the build, because that is the fastest way to make progress, and then some of it silently stays there. Three years later you are still paying $14 a month for a Sentry seat on a project you finished in 2023.

Two acceptable structures. Either the client holds the accounts and adds you as a collaborator, which is cleanest, or you procure on their behalf and pass costs through at cost against receipts, with a stated cap above which you need approval.

Client is responsible for all third-party costs including hosting, domains, certificates, API usage and paid software licences. Where Developer procures these on Client's behalf, they will be invoiced at cost, and Developer will obtain written approval before incurring any single item above $200. All such accounts will be transferred to Client's ownership at handover.

The last sentence is the one that saves you money, so do not drop it.

Payment terms, and the statutory leverage behind them#

Three US states now require your client to give you a written contract and pay within 30 days by default, and not one page ranking for this search mentions any of them.

This is the newest leverage available to freelance developers and almost nobody in the SERP knows it exists, because the pages are published by SaaS vendors with no legal-update motion.

Sources: Illinois Department of Labor, New York State Department of Labor, and California SB 988.

Read the thresholds again, because they are lower than almost any development project. A $250 California threshold means essentially every engagement is covered. The duty falls on the hiring party, not on you, which means a client who never sent you paper is already in breach before the payment dispute starts.

We have jurisdiction-level detail in the Illinois Freelance Worker Protection Act, the California Freelance Worker Protection Act, and freelance payment laws by state.

If you invoice UK clients, the Late Payment of Commercial Debts rules give you statutory interest of 8% above the Bank of England base rate on B2B debts, plus fixed-sum recovery compensation. One catch worth knowing: you cannot claim statutory interest if your contract specifies a different rate, so a badly chosen 1% monthly clause can actually leave you worse off than saying nothing.

Your payment clause itself should carry a deposit, a milestone schedule tied to acceptance rather than to dates, a stated late fee, and a suspension right. On the suspension right: state that you may pause work on any invoice more than 15 days overdue, and that timelines extend accordingly. It is the difference between a leverage point and a grievance. See freelance payment terms, how much deposit to charge, and stop work clauses for unpaid invoices.

Liability and indemnity: the clauses that can exceed your fee#

Two of the five ranking pages contain no limitation of liability at all, and one pairs an absolute non-infringement warranty with a one-way, uncapped indemnity.

Read that combination slowly, because it describes a real document that ranks for this search and has been used thousands of times. You warrant that the software infringes nothing. You indemnify the client for all costs of any IP claim. There is no cap anywhere in the agreement. A single unlucky dependency and your exposure is unbounded against a fee that might have been $8,000.

Three fixes, in order of importance.

1. Cap total liability at fees paid#

Neither party's aggregate liability under this Agreement will exceed the total fees paid by Client to Developer under it. Neither party is liable for indirect, incidental, consequential or special damages, or for loss of profits, revenue or data.

Fees paid is the number a solo developer can survive. Some clients push for a multiple of fees. Anything you agree to should still be a number, not infinity. Carve-outs for confidentiality breach and wilful misconduct are normal and worth conceding to close the point.

2. Make indemnity mutual and tie it to adjudication#

An indemnity that triggers on "any claim" means you pay defence costs for a meritless allegation. Tie it to a claim finally determined, or at minimum to a claim arising from your actual breach, and make the client indemnify you for materials they supplied. Client-supplied content is a genuine source of infringement claims, and you have no ability to clear it.

3. Do not sign an absolute warranty#

Every "will not infringe" should read "to Developer's knowledge, and excluding third-party components disclosed under the schedule." You cannot audit the licence chain of every transitive dependency, so do not promise that you did.

One of the ranking pages tells readers that indemnification is a red flag to remove entirely. That advice will lose you the deal. Mutual, capped indemnity is standard commercial practice. The negotiation is over shape, not existence.

Non-compete, non-solicit, and your portfolio#

The FTC's nationwide non-compete rule is gone, removed from the Code of Federal Regulations effective 12 February 2026, so enforceability is once again a question of state law.

The sequence matters if a client cites the rule at you. A federal court set the rule aside nationwide in August 2024. The Commission voted in September 2025 to accede to vacatur, and the Federal Register notice removing 16 CFR part 910 took effect on 12 February 2026.

What did not go away is the FTC's case-by-case authority. On 15 April 2026 the Commission ordered Rollins, Inc. to stop enforcing non-competes against more than 18,000 employees and sent warning letters to 13 other companies in the same industry. So the posture in 2026 is: no blanket federal ban, active federal enforcement against overbroad ones, and state law doing the heavy lifting. California, for instance, remains hostile to them.

For a freelance developer, the practical positions are these.

Non-compete: decline. A clause saying you will not work for anyone offering "substantially similar products or services" would end your business, and one of the ranking templates ships exactly that language with no geographic or duration limit, in a document marketed to freelancers. If a client insists on something, offer a narrow project-specific exclusivity for a defined term, and price it, because you are selling capacity you can no longer sell elsewhere.

Non-solicit: usually acceptable. Twelve months, limited to the client's employees and customers you actually worked with, with the standard carve-out for people who respond to a general advertisement.

Portfolio rights: ask for them explicitly, because the assignment and the NDA together will otherwise strip them. This is the one place where the strongest ranking page gets it right.

Notwithstanding the assignment above, Developer retains a perpetual, non-exclusive licence to display the deliverables and describe the work performed in Developer's portfolio and marketing materials, excluding any Confidential Information.

If the client needs a delay for a launch embargo, agree an embargo date rather than a permanent bar. "Not until public launch" is reasonable. "Never" means the work you spent four months on cannot help you win the next four months of work.

When you touch the client's users' data#

If your build stores or processes personal data on the client's behalf, you are a processor under GDPR Article 28 and the contract terms are mandatory, not optional, and none of the five ranking pages includes them.

This is not exotic. A contact form that writes to a database, an analytics integration, a user account system, a CRM sync: all of that is processing personal data for the client's purposes.

Article 28(3) requires a written contract that sets out the subject matter and duration of the processing, its nature and purpose, the types of data and categories of data subject, and then binds you to a specific list: process only on documented instructions, keep it confidential, apply Article 32 security measures, get authorisation before engaging sub-processors, help with data subject requests, delete or return data at the end, and make information available to demonstrate compliance.

You do not need to draft this from scratch. Most clients with any compliance function have a data processing addendum ready. Ask for it and attach it. If they do not have one, the ICO's guidance on controller-processor contracts lists the required terms plainly.

Add one thing the DPA usually will not cover: who is responsible when there is a breach. A solo developer should not carry unlimited liability for an incident originating in the client's hosting, their staff, or a third-party service they chose. Tie your responsibility to your own security failures and let the liability cap apply.

A minimum viable developer contract#

If you take nothing else from this page, these are the clauses that carry actual financial consequence. In this order.

1. Scope with exclusions and a browser/device matrix. What is in, what is explicitly out, and what it runs on.
2. Acceptance: staging environment, written criteria, ten business days, deemed accepted on silence.
3. Change orders: anything outside the criteria is quoted and approved in writing before it is built.
4. Payment: deposit up front, milestones tied to acceptance not dates, stated late fee, right to suspend on overdue invoices.
5. IP: work-for-hire recital, express assignment effective on payment in full, further assurances, background IP carve-out, portfolio licence back.
6. Open source: component schedule as a deliverable, copyleft requires approval, knowledge-qualified non-infringement warranty.
7. Handover: the numbered artefact list, with completion defined.
8. Warranty: thirty days, conforming to acceptance criteria, with exclusions, and maintenance explicitly separate.
9. Third-party costs: client's responsibility, approval threshold, accounts transferred at handover.
10. Liability: capped at fees paid, no consequential damages, mutual indemnity.
11. Restrictions: no non-compete, narrow non-solicit, portfolio rights retained.
12. Data: DPA attached if personal data is involved, breach responsibility allocated.
13. Termination: either party on notice, you get paid for work completed and accepted, plus a kill fee if the client walks mid-milestone.
14. Boilerplate: governing law, independent contractor status, entire agreement, written amendments.

Fourteen items. A good developer agreement is six to eight pages, not thirty.

For the general-purpose version of this checklist across all freelance work, see what should be in a freelance contract, and freelance contract red flags for what to strike when a client sends you theirs.

Where Raoura fits#

Disclosure: Raoura is our product. It is a $17 a month client and project tool for solo freelancers, and it is not a law firm. What it does is make the clauses above happen on every project instead of only the ones where you were paying attention.

The failure mode is not that freelance developers do not know these clauses. It is that the good contract lives in a folder, the last project's version got edited in a hurry, and the small job that turned into a nightmare was the one that went out on a two-paragraph email.

A template library fixes that by making the careful version the default version.

!Raoura's contract template library, where reusable agreements and clauses live so the same terms go out on every project

The liability cap, the payment-conditioned assignment, and the open source schedule from this article only protect you if they are in the template you actually send, not the one you meant to update.

The second half is acceptance. Everything in the payment section above depends on being able to say when a deliverable was delivered, when the review window started, and what was invoiced against it. That is a record-keeping job, and it is the one that quietly decides whether a deemed-acceptance clause is enforceable or just words.

!Raoura project milestones, each tied to a named deliverable with its own approval state and invoice

Milestones named after acceptance criteria are what turn the ten-business-day review clause into an invoice date instead of an argument.

One thing worth stating plainly given the subject: Raoura never holds your money. Client payments go through your own Stripe account, directly to you, with no commission taken. We wrote about why that matters in why your client tool should never touch your money.