Who Owns the Software You Paid For? A Founder's Guide to IP, Escrow and Handover

Overview

So you paid an agency to build your software — you own it, right? Not necessarily. Payment buys the service and the deliverables; who owns the code is a separate question, answered by default rules and your contract. This guide explains where ownership starts, how it moves or is licensed, which components stay licensed, what escrow covers, and the handover that makes ownership usable.

Key Points

• Payment buys the service and the deliverables; copyright in contractor-written code starts with the creator, moving only under the law's exceptions or a valid agreement.
• US “work made for hire” turns on the statute, not the contract's label: employment, or a listed category with a signed written agreement.
• Escrow is continuity, not ownership: release does not by itself transfer copyright; permitted use depends on the relevant licence and escrow terms — and, for hosted software, recovery needs more than code.
• Ownership and operability differ. Accounts and deployment rehearsals in an authorised environment show operational independence — not legal title.

Payment, ownership and access are different

The gap between paying for software and owning it can surface when a relationship ends, or when due diligence asks who holds the rights and the answer involves asking the agency. Invoice and ownership are different things. US law is explicit: ownership of a copyright is distinct from ownership of any material object in which the work is embodied, and transferring the object does not of itself convey any rights (17 U.S.C. §202). Paying buys the service and the deliverables; the rights are a separate step.

Under the US Copyright Act, copyright vests initially in the author (§201(a)). Code written by the vendor's employees within the scope of their employment makes the employer the author — the first branch of “work made for hire” (§§101, 201(b)). Commissions qualify only within one of the nine categories §101 lists — collective-work contributions, parts of audiovisual works, translations, supplementary works, compilations, instructional texts, tests, answer material, atlases — and only if the parties expressly agree in a signed written instrument that the work is work made for hire. A custom application does not automatically qualify; the statutory categories, signed agreement and actual relationship determine whether commissioned work is work made for hire.

The UK starts in the same place: under the CDPA 1988 the author is first owner (s.11(1)); employee work made in the course of employment belongs first to the employer, unless the contract says otherwise (s.11(2)); contractors fall outside that exception. Both systems require a signed writing for an ordinary assignment: in the US, a transfer of copyright ownership, other than by operation of law, is valid only if evidenced by a signed written note or memorandum (§204(a)); in the UK, an assignment is not effective unless in writing signed by or on behalf of the assignor (s.90(3)) — the IPO's GOV.UK guidance says the same in plain terms. Without an assignment, a client may hold only an implied licence — permission inferred from the circumstances, usually limited to the purpose commissioned, and weaker than ownership when you need to adapt, sell, or raise money.

One note on how this guide is built: mechanics passages describe how these arrangements typically work; advice passages describe what is worth asking for. This article is general information, not legal advice: rules vary by country and contract, so have a lawyer review a valuable build's agreement.

Assignment or licence: how the rights can be arranged

An assignment transfers ownership: the client becomes legal owner of the rights the assignor actually holds and the assignment covers. A licence leaves ownership with the developer and grants permission on defined terms — exclusive or non-exclusive, perpetual or limited. Where full control matters, assignment is the cleaner route. Separate background IP (the vendor's pre-existing tools and libraries, licensed to you) from project IP (the code built for you, which is assigned), and treat code and other deliverables separately. On moral rights, UK law is narrower for code than often assumed: neither the attribution right (CDPA s.79(2)(a)) nor the right to object to derogatory treatment (s.81(2)) applies to a computer program. Other deliverables differ — designs and documentation are not computer programs, and rights such as false attribution have their own scope — so where rights exist, agreements often add waiver or consent wording.

What the IP clause should actually cover

Look for specifics rather than reassuring labels. The clause should say which rights are assigned — the IP in the deliverables, including drafts — and when the transfer happens. A common approach is for the assignment to take effect on full payment: ownership arrives with payment, and the developer is not left unpaid. Payment itself guarantees neither delivery of every file, account or asset nor ownership of every right — those come from the delivery and IP terms. For the wider mechanics of scope, acceptance and exit clauses, see our guide to fixed price vs time and materials.

Two further points deserve attention. First, the chain: a build may involve employees, freelancers and subcontractors, and an assignment transfers only rights the assignor holds. What protects you is not assuming every contributor personally owns their part, but a contract obliging the vendor to secure the needed assignments or licences from its personnel and subcontractors, with consent required before subcontracting, so the chain reaches you unbroken. Second, originality: the vendor should warrant the work is original or properly licensed and infringes no one else's IP — including AI-assisted code, where the position can be unclear. Portfolio use should also be agreed upfront, in writing.

Components that stay licensed: third-party and open-source parts

Modern software is rarely all new code. Third-party and open-source components are not the vendor's to assign — their rights belong to their own owners — so they remain licensed rather than owned by you, on their licences' terms. Your agreement should require disclosure of what is included, confirmation the licences suit your intended use, and a statement of who pays ongoing fees. Where the vendor retains pre-existing components built into your product, your licence needs the same care: what you may do, for how long, one-off or recurring fee.

When ownership is not on the table: escrow

Escrow can protect access to licensed software, whether installed on your own infrastructure or hosted by a supplier. Source-code escrow exists for this conflict: the vendor deposits the code and the materials needed to maintain it with an independent agent, released only if agreed conditions are met. Typical triggers: the vendor's insolvency, ceasing support, materially breaching the agreement, or announcing the product's end of life. For hosted software, code alone may not be enough: running a SaaS product also needs data access and exports, configurations, dependencies and a recovery plan — escrow providers describe SaaS arrangements as covering that full environment. The agreement fixes the deposit's scope and your post-release rights. Release does not by itself transfer copyright; permitted use depends on the relevant licence and escrow terms. Whether a release happens depends on the agreement's triggers, verification, notification and dispute procedures and on applicable law: the beneficiary must claim the release, the vendor typically gets a window to dispute it, and a contested claim can go to arbitration.

Escrow is worth negotiating when your business would be stranded without the software: a system you depend on daily. Continuity risk does not follow vendor size alone — a large supplier can retire a product line; a small one can be stable — so judge the dependency and the cost of failure, not the headcount. For a custom build, holding the repository supports day-to-day control but settles neither ownership nor continuity: the assignment and handover clauses carry the legal weight.

The other half: operating the stack without the vendor

Owning the rights and being able to run the system are different achievements — and neither proves the other. Legal ownership alone does not ensure operability — a flawless assignment can still leave you unable to deploy tonight. Controlling the accounts shows operational independence, not legal title. The practical recommendation: your product's dependencies should live in your company's name — subject to each platform's account arrangements — with the delivery team added as collaborators whose access you can remove. That means repositories in your organisation, cloud and hosting on your billing, domains in your registrar account, app store accounts in your entity's name, and third-party services issued from your accounts, not the vendor's.

Documentation needs to be short and current, written for someone walking in cold: an architecture overview of a page or two, runbooks for deploy, rollback, secret rotation, backup restore and likeliest alerts, a decision log, and a known-issues list. Ask for infrastructure defined as code, in your repository, applied through a pipeline — console-clicked setups are hard to reproduce. Documents alone are not sufficient: a serious handover ends with hands-on demonstrations in a suitable authorised environment — a staging setup or a controlled production slot, not improvised access: a recorded codebase walkthrough, a supervised first deploy by your own engineer, rollback and backup-restore rehearsals, secret rotation with vendor access removed, and a support window.

Ownership checklist before the final invoice

• The assignment is signed and names the deliverables and rights it covers.
• Background IP and third-party components are listed, with licence terms for each.
• Assignments or licences are secured from the vendor's personnel and subcontractors, so the chain reaches you.
• Rights in other deliverables — design, documentation, portfolio use — are settled in writing.
• The vendor warrants the work is original or properly licensed, non-infringing.
• Where platform arrangements permit, repositories and all accounts sit in your organisation, on your billing, with vendor access removable.
• A README takes a new engineer to a running copy; infrastructure is code.
• Deploy, rollback and backup restore are rehearsed from the runbooks in an authorised environment.
• A post-handover support window, named contact and exit terms are in writing.

Frequently asked questions

Does paying for the code mean I own it?

No — not by itself. Payment buys the service and the deliverables; copyright starts with the creator, and only the law's exceptions or a valid signed assignment move it.

What if my vendor used open-source libraries in my product?

That is normal — but the libraries remain licensed, not owned, by you or the vendor. Require a component list and confirmation their licences suit your use.

When does software escrow make sense for a startup?

When your operations would be stranded without the vendor: critical software they host or supply. Judge the dependency and what failure would cost, not the vendor's size — and for hosted software, check the deposit covers what recovery needs: data, configurations and dependencies.

Sources

• 17 U.S.C. § 101 — Definitions (incl. “work made for hire”) (US statute)
• 17 U.S.C. § 201 — Ownership of copyright (US statute)
• 17 U.S.C. § 202 — Copyright vs the material object (US statute)
• 17 U.S.C. § 204 — Transfers of copyright ownership (US statute)
• US Copyright Office — Works Made for Hire (official guidance)
• CDPA 1988, s.11 — First ownership of copyright (UK statute)
• CDPA 1988, s.90 — Assignment and licences (UK statute)
• CDPA 1988, ss.79/81 — Moral-rights exceptions (UK statute)
• GOV.UK (IPO) — How copyright protects your work (official guidance)
• Codekeeper — What Is Software Escrow? (escrow provider; supplementary)
• Sprintlaw UK — Contractor IP Ownership in the UK (law-firm; supplementary)
• Axentis — Owning Your Stack After an Outsourced Build (agency; supplementary)

Commissioning a build? Our project cost calculator gives indicative cost and timeline ranges from your scope and complexity. If you are working through these IP, escrow and handover questions yourself, discuss your project with us — and if you are still shaping what to build first, our SaaS development planning guide covers defining deliverables before anyone estimates against them.