In most jurisdictions, the developer, agency, or freelancer who writes the code keeps the legal rights to it by default — paying for the work does not automatically make the founder the owner unless a contract says so in writing. The gap between "I paid for it" and "I own it" is one of the most common, expensive misunderstandings in working with outside developers. This guide covers what code ownership means, the clause that closes that gap, what real ownership requires beyond a signature, and how to run a clean handover when an engagement ends.
Who owns the code by default, before any contract exists?
Copyright law in most countries assigns authorship — and the rights that come with it — to whoever actually wrote the code, not whoever paid for it. That's the opposite of what most founders assume. An employee who writes code as part of their job usually creates work the employer owns automatically, because that relationship is governed by employment law. An outside developer, agency, or freelancer is a different legal relationship entirely: absent a written agreement stating otherwise, the code they produce for you can remain their property even after you've paid the final invoice. They may grant you a license to use it, but a license is not the same as ownership — it can come with conditions, or not extend to future changes, resale, or exclusive use.
Does paying for the work make it "work for hire"?
Not automatically, no. "Work for hire" is a specific legal term, and its rules vary by jurisdiction. In the US, for example, it applies cleanly to employees, but for independent contractors it only covers a narrow list of commissioned work categories, and only when both sides sign a written agreement explicitly calling the work "work made for hire" before work begins — software often falls outside that list entirely. Many other jurisdictions don't recognize the concept in the same form at all, and rely instead on general copyright and assignment rules. The practical takeaway is the same everywhere: don't rely on the phrase "work for hire," and don't rely on the invoice being paid. Rely on an explicit written clause.
What clause should a founder confirm before work starts?
The clause to look for is an IP assignment clause — language that explicitly transfers all rights, title, and interest in the code, designs, and related deliverables from the developer or agency to the founder or the founder's company, typically upon full payment. A well-written clause names exactly what's being assigned (source code, object code, documentation, designs), states that the assignment is irrevocable, and addresses any pre-existing tools or libraries the developer brings in that they don't have the right to assign outright. This clause should be agreed and signed before development begins, not negotiated after the product is built, when leverage has already shifted. A vague sentence like "the client owns the final product" is not a substitute for an assignment clause — ask directly whether IP transfers, and exactly when.
What does actually owning the code require, in practice?
Legal ownership is close to meaningless if you never get your hands on what you own. A founder with full IP rights on paper but no access to the repository or hosting account is still fully dependent on the developer who built it. Owning the code in practice means having admin-level access to the source code repository, the production and staging environments, the domain and DNS settings, and any third-party services the product depends on. A promise to "send it over if needed" is not access — it's a dependency you're still carrying. Confirm access early, not once the relationship is ending and cooperation gets harder.
What should a healthy project handover include?
A clean end to an engagement — whether it wraps up normally or ends abruptly — should leave a founder with everything needed to keep the product running without the original developer. At minimum, that means:
- Full access to the source code repository, including commit history, under an account the founder controls.
- Documentation covering setup, architecture, environment variables, and any non-obvious decisions.
- Admin credentials for hosting, the domain registrar, and deployment tools — not read-only or temporary access.
- No orphaned third-party accounts — payment processors, analytics, APIs — that only the developer can log into.
- A brief written confirmation that IP has been assigned and access has been transferred in full.
A quick check before signing anything
Before a contract is signed, ask two direct questions: does this agreement explicitly assign IP to us, and exactly when does that transfer happen? If either answer is vague, the vagueness itself is the risk — not the developer's intentions.
Frequently asked questions
If I paid a freelancer to build my app, do I automatically own the code?
Not necessarily. In most jurisdictions, ownership doesn't transfer automatically just because payment was made — it depends on what the contract says. Without an explicit IP assignment clause, the freelancer may retain rights to the code even after being paid in full.
What's the difference between a license to use code and owning it?
A license lets you use the code under conditions the owner sets, while ownership means you hold the underlying rights yourself. A license can be limited, revocable, or restricted to specific uses; only an assignment of IP makes the founder or company the actual owner.
What access should I request when a development engagement ends?
At minimum, admin access to the source code repository, hosting and deployment accounts, the domain registrar, and any third-party services the product depends on. Ownership on paper without this access still leaves you dependent on the original developer.
Is this legal advice on how to handle code ownership with my developer?
No — this is general practical guidance, not legal advice. IP law and contract enforceability vary by jurisdiction and by the exact wording used, so confirm the specifics of your situation, and any contract before you sign it, with a lawyer for your specific case.