Hanad KubatVisit Website →
← Back to blog

Own Code from First Commit: What Founders Must Insist On in Contracts

October 6, 2026
Own Code from First Commit: What Founders Must Insist On in Contracts

By default, the person who writes the code owns it, not the person who paid for it. If you hire a freelancer or agency without a signed assignment, you may have paid for software you only have permission to use. The single fix: demand a written IP assignment on payment, or a broad perpetual transferable license, plus delivery of source code and credentials.

TL;DR:

  • Without a signed IP assignment or broad license, you only have permission to use the code, not ownership, which can limit future development or sale.
  • In the U.S. and UK, ownership transfer requires clear written signatures and intent, making vague agreements or oral promises legally insufficient.
  • The contract should include precise deliverables, acceptance criteria, and remedies to ensure practical control over the code after payment.
  • Final handover must include full repository access, build instructions, credentials, and ownership of related assets like domains and keys.
  • Recording all agreements, amendments, and licenses from the first commit supports legal defense and clarity during due diligence or disputes.
Hanad Kubat
Own Your Product From Day One
Build a working first version with clear ownership, fixed scope, and code handed over from the first commit.
Visit Hanad Kubat

Table of Contents

What assignment and license mean, and why jurisdiction matters

An assignment transfers ownership of the copyright itself. Once signed, you become the legal owner, free to modify the code, hire someone else to extend it, sell the business, or sublicense it to a partner. A license only grants permission to use the code under specific terms: it can be limited by time, territory, or field of use, and the original developer still owns the copyright.

The difference sounds abstract until you try to change developers or raise money. A narrow license can block both.

Jurisdiction changes the mechanics:

  • In the United States, copyright initially belongs to the author unless the work qualifies as a "work made for hire," and even then, ownership transfers to the hiring party only under specific statutory categories; otherwise a signed written agreement is required, as explained in Circular 30 on works made for hire.
  • Under U.S. Title 17, initial ownership vests in the author, any transfer must be in writing and signed, and recording the transfer can establish priority if there is ever a conflicting claim, according to Title 17's provisions on copyright ownership.
  • In the United Kingdom, an assignment of copyright has no legal effect unless it is in writing and signed by the person giving up the rights, a rule set out directly in Section 90 of the Copyright, Designs and Patents Act 1988.

None of this requires magic words. What matters is clear intent, a signature, and ideally a schedule listing exactly which code, repositories, or deliverables the assignment covers.

There's also a distinction worth holding onto: access is not the same as ownership. You can have the admin password to a server and still lack any legal right to the code running on it. Conversely, you can own the copyright outright and still need the developer to hand over the actual files. Both the legal transfer and the practical handover have to happen, and neither one substitutes for the other.

Clause-by-clause checklist for your software contract

Most disputes trace back to a contract that never said who owns what. Here's what to insist on before signing anything.

  1. IP assignment clause. Language stating that all intellectual property in the deliverables is assigned to you upon full payment (or upon creation, with payment as consideration), signed by both parties. If assignment isn't available, the fallback is a license that is worldwide, perpetual, irrevocable, transferable, and sublicensable, which gets you most of the practical rights of ownership without the title.
  2. Deliverables schedule. A specific list: source code, a tagged release matching what's in production, build and deploy scripts, technical documentation, a full dependency list, copies of third-party licenses and notices, and transfer of any credentials needed to run the system.
  3. Acceptance criteria. Defined tests or conditions that determine when a deliverable is considered complete, tied to payment milestones, so "done" isn't a matter of opinion.
  4. Warranties and indemnities. A statement that the developer has the right to assign the work, that it doesn't infringe third-party rights, and that the developer will indemnify you if it does. Where relevant, a moral rights waiver, since in some jurisdictions a creator can object to modifications even after assigning copyright.
  5. Survival clause. Confirmation that IP and confidentiality obligations survive termination of the contract, so a messy breakup doesn't also cost you the code.
  6. Remedies for withholding access. A specific consequence, such as a penalty or right to immediate escrow release, if the developer refuses to hand over code or credentials after payment.

A UK government procurement template takes exactly this approach: it assigns new intellectual property rights to the buyer by default and requires delivery of source code, documentation, and supporting materials within set timelines, which is a useful model to borrow language from even outside public contracts, as shown in Call-Off Schedule 1 on intellectual property rights.

Pro Tip: Attach a signed schedule listing the exact repositories, files, or modules covered by the assignment: vague references to "the work" invite disputes later.

The technical handover checklist you need on delivery

Owning the copyright means nothing if you can't actually run the software. Legal ownership and practical control are two separate problems, and the contract should solve both.

On final delivery, you need:

  • Full access to the code repository, including commit history, not just a zip file of the latest version.
  • A tagged release that matches exactly what's running in production.
  • Written build and deploy instructions, plus any CI/CD configuration or pipeline artifacts.
  • A database export or clear instructions for migrating your data.
  • Ownership transfer of the domain name and cloud or hosting accounts, not just access to them.
  • All SSH keys, API keys, and environment configuration variables, rotated after handover for security.
  • A list of open-source components used and their licenses, so you know what obligations come with them.

Verify the build works before you release final payment: have someone, ideally not the original developer, clone the repository and run it from the instructions provided. For larger engagements, a small holdback, released only after a successful independent build, gives the developer an incentive to make the handover work on the first try rather than the third. My software project handover process is built around exactly this sequence.

Common mistakes founders make with code ownership

The same handful of errors show up again and again in contracts I've reviewed or inherited.

  • Assuming payment equals ownership. It doesn't, in the US or the UK. Fix it by requiring a signed assignment clause or explicit broad license terms, not an implied understanding.
  • Accepting a narrow license without noticing. A license limited by territory, time, or field of use can block you from expanding, pivoting, or selling the business. Push for worldwide, perpetual, transferable, and sublicensable terms, or take assignment outright.
  • Letting the developer keep essential accounts. If the vendor controls your domain registrar, cloud account, or payment processor login, you don't really own your product. Require full transfer, not shared access.
  • A vendor who won't list third-party licenses. Refusal to disclose open-source dependencies is a red flag: it usually means nobody checked, which is a liability you're about to inherit.

How I structure fixed-price builds and handovers

One name on the contract: mine. There's no agency layer and no junior developer touching your code, which means no ambiguity about who's accountable for the IP terms.

Code ownership starts from the first commit, not the final invoice. You get repo access at each milestone, scope frozen at kickoff, so you can watch the product take shape and never wonder what you're actually paying for.

Acceptance criteria are explicit before work starts, not negotiated after delivery. This matters most at two moments: when you're raising money and due diligence looks for a clean chain of ownership, and when you need to hire a different developer later and they need a codebase they can actually read. A due diligence checklist built around these same questions is worth running against any contract before you sign it.

Handling future improvements and derivative works

Ownership clauses often cover the initial deliverable and go silent on everything built afterward. That gap causes real problems. If a developer makes improvements under a separate engagement, or if your in-house team extends the original codebase, the contract should state upfront that all derivative works and future improvements are also assigned to you, not just the version delivered on day one.

This matters most when you bring on a second developer or agency later. Without clear language, a new contributor's additions could be covered by their own, different terms, fragmenting ownership across pieces of the same product. The fix is simple: every contract for ongoing or follow-up work should repeat the assignment clause, not assume the original agreement still applies.

It's also worth separating your own code from any open-source components it depends on. You can own everything you wrote while still being bound by the license terms of a library you imported, such as an obligation to share your own modifications under the same license. A SaaS platform comparison is a useful reminder of how much future flexibility depends on getting this right early, since switching platforms or vendors later is far harder when ownership of derivative work was never pinned down.

Handling future improvements and derivative works — overview diagram

Documenting ownership history and provenance

A contract that assigns ownership is only as strong as the paper trail behind it. Keep a record of every agreement, amendment, and invoice tied to the code, in one place, from the first commit onward.

Three habits make this easy to maintain. First, attach a schedule to every assignment listing the specific repositories or files covered, rather than a vague reference to "the deliverables." Second, keep signed copies, not just email threads, since UK and US law both require a signature for an assignment to take legal effect. Third, log every third-party component and its license at the time it's added, not reconstructed later when a buyer or investor asks.

This record matters most when you least expect to need it: during due diligence, a funding round, or a dispute with a former contractor. A clear provenance trail, where every line of code can be traced to a signed agreement, is far easier to defend than a "work-for-hire" label you're hoping holds up in a jurisdiction that never recognized it that way.

The gap between what contracts promise and what founders actually get

Most advice on this topic stops at "get an IP assignment clause," as if the clause alone solves the problem. It doesn't. I've seen contracts with a clean assignment clause where the founder still couldn't get the domain transferred, the database exported, or a list of open-source dependencies, because nobody made the handover itself a contractual obligation with a deadline.

The legal right and the technical delivery are two different fights, and founders tend to only prepare for one of them. A signed assignment protects you in a dispute years from now. A handover checklist protects you next week, when you need to actually ship a change and discover the previous developer never gave you the build instructions.

Two paths joining at usable code ownership

If you only have room to negotiate one thing hard, I'd argue it's the deliverables schedule, not the assignment language. Ownership you can't operationalize is a legal victory with no practical value.

How I handle code ownership on every project

Every project I build starts with the prototype as the spec, and every line is written by me, no juniors touching your codebase. You own the code from the first commit, which means there's no handover negotiation at the end because there was never a point where you didn't have access.

This fits two situations particularly well: a founder whose AI- or no-code-built prototype stalled around 70%, usually right at login or payments, and a founder who inherited code from an agency that nobody on their team can actually read. In both cases, the first real version or the rebuild gets delivered milestone by milestone, with scope frozen at kickoff and no surprise invoices along the way.

If you want a working product built in weeks, not months, with clean ownership from day one, Your app, websites outlines how fixed-price builds work and what's included at each stage.

— Hanad Kubat

FAQ

Who owns the code?

By default, the person or company that wrote the code owns the copyright, not the person who paid for it, unless a signed written agreement says otherwise. In the US this follows from work-for-hire rules, and in the UK an assignment must be in writing and signed to be valid under CDPA Section 90.

What are the 7 rules of a contract?

There's no single fixed list, but most contract law frameworks require offer, acceptance, consideration, intention to create legal relations, capacity, certainty of terms, and legality of purpose. For software contracts specifically, the IP assignment or license clause is the term that most often gets overlooked despite being this critical.

What are code contracts?

A code contract, in the context of software ownership, is a development agreement that specifies who owns the code produced, what gets delivered, and under what terms the client can use, modify, or resell it. It typically includes an assignment or license clause, a deliverables schedule, and warranties covering third-party intellectual property.

What are the 5 components of a contract?

The core components typically cited are offer, acceptance, consideration, mutual intent to be bound, and capacity to contract. In software agreements, these generalized components get layered with specific clauses covering IP ownership, deliverables, and acceptance criteria that determine when the work is considered complete.

How is ownership different from having a license to use software?

Ownership means you hold the copyright and can modify, resell, or sublicense the code freely. A license only grants permission to use the code under agreed terms, which can be restricted by time, territory, or purpose, while the developer retains the underlying copyright, a distinction explained in Cornell Law School's overview of work-for-hire doctrine.

Sources