Who Owns the Code When You Hire a Software Firm?

Who owns the code you paid for? The short answer

By default, the person or company that creates the code owns it—not the person who pays for it. If you hire a software development company, ownership does not transfer automatically just because money changed hands. It must be assigned in writing, and in 2026 that is only the first layer of the answer.

The practical test is bigger than copyright language. Real ownership has three layers:

• Legal ownership: who holds the copyright and related IP rights?
• Operational ownership: can another competent team take the repo, docs, tests, CI/CD, and accounts and ship a change in two weeks?
• Provable ownership: can you show a clean authorship trail, especially when AI helped generate parts of the code?

If one of those layers is missing, you may own the code on paper and still be locked out in practice.

Why does the person who paid not own the code by default?

Because software ownership follows authorship first, not payment first. That is the default assumption in copyright law and in most vendor relationships. A founder can fund the work, direct the work, and approve the work, yet still not own the underlying code unless the contract clearly transfers those rights.

The work-for-hire trap for contractors and agencies

Many buyers assume “work for hire” solves everything. It often does not.

In the U.S., work-for-hire is narrower than most non-lawyers expect. It can apply automatically in employer-employee relationships, but for contractors it usually requires very specific conditions and written terms. If you hire a software development company and the agreement uses vague language like “client owns all deliverables,” that may be weaker than an actual assignment clause transferring copyright and related IP.

That is why many diligence issues show up later: the buyer thought they purchased ownership, but the paper trail only purchased usage rights, a license, or an unclear promise.

Background IP vs foreground IP: what a fair split looks like

The cleanest software development IP ownership structure separates what existed before the engagement from what was created during it.

• Background IP: the agency’s existing frameworks, libraries, templates, internal tools, and reusable methods.
• Foreground IP: the custom work created specifically for your product.

A fair deal can let the vendor keep background IP while assigning the foreground IP to you. The danger is when that split is not explicit. Then a founder may unknowingly depend on vendor-owned building blocks that are not fully transferable, or discover that the “custom” app sits on proprietary scaffolding they do not control.

The Three Layers of Real Ownership

This is the framework founders should use before signing any build agreement.

Layer 1: Legal ownership

Before work starts, the contract should answer four questions clearly:

• Who owns the foreground code, design, documentation, and other deliverables?
• What exactly is assigned, not just licensed?
• What background IP remains with the vendor?
• What open-source components are included, and under what licenses?

For a buyer, the right language is usually less important than the right outcome: you want an assignment of all custom-created deliverables, a defined list of excluded pre-existing materials, and a representation that the vendor has the right to grant what it is granting.

If you are reviewing a contract, look for the difference between license and assignment. A license gives permission. An assignment transfers ownership.

Layer 2: Operational ownership

Legal ownership is not enough if only one vendor can run the system.

Use the Two-Week Handover Test: could a competent new senior team take your repo, documentation, tests, CI/CD setup, cloud accounts, secrets management, and deployment process, then ship a safe change within two weeks?

If the answer is no, you do not truly control the asset.

This is where many build relationships become quiet lock-in:

• No meaningful documentation
• No test coverage or brittle tests
• Infrastructure only the vendor can access
• Architecture known only to one engineer
• Deployment pipelines tied to vendor-managed credentials
• Dependencies on private tools or unpublished scripts

You can own code and still be unable to operate it. That is de facto dependency, which matters just as much during a founder transition, a financing process, or an acquisition review.

Layer 3: Provable ownership

In the AI era, the question is not only whether you own the code. It is whether you can prove who authored it, how it was produced, and whether the chain of authorship supports your diligence story.

That matters because uncoached AI-generated output can create a copyrightability problem. If code is generated with little human shaping or review, the authorship record becomes murky. Investors and acquirers will ask whether the code was written by humans, whether AI was used as a tool, and whether the resulting work can be defended as human-authored enough to support copyright claims.

For founders who prototyped with Replit, ChatGPT, Claude, or similar tools, this is not theoretical. “Does ChatGPT own my code?” is the wrong framing. The real question is whether your team can establish that humans made the substantive creative and technical decisions, and that AI was used as an instrument—not the author.

AI does not remove the need for authorship. It raises the standard for showing that a human shaped the work, reviewed it, and accepted responsibility for the code that shipped.

Does AI change who owns the code?

It changes the diligence burden, not the business necessity.

As a buyer, you should expect an AI-assisted workflow to have three properties:

• Human direction: senior engineers define the architecture, boundaries, and acceptance criteria.
• Human review: every meaningful change is reviewed by a qualified engineer, not merged from raw output.
• Human accountability: commit history, reviews, and issue tracking show who decided what and why.

This is the difference between coached AI and vibe-coded AI. Coached AI can accelerate delivery while preserving a defensible authorship trail. Vibe-coded systems may be faster at first, but they can leave you with unclear provenance, weak quality control, and a harder story in diligence.

For a founder heading into fundraising or acquisition, that provenance matters. A clean repository history, meaningful pull request reviews, and engineering discipline are not just process artifacts; they are evidence that the product is owned and operated like a real asset.

The lock-in traps that survive a signed IP clause

Some vendors are perfectly willing to sign an ownership clause and still create dependency through execution. Watch for these traps:

• Repo not in your org: if the source code lives in the vendor’s account, control is still external.
• No environment handoff: if production access, cloud credentials, and CI/CD live elsewhere, you cannot operate independently.
• No tests: without tests, every change becomes risky tribal knowledge.
• No docs: if onboarding a new engineer takes days of vendor explanation, you have operational lock-in.
• Bus factor of one: if one person knows the architecture, you do not own a maintainable system.
• Proprietary foundation hidden under “custom” work: if the core is a private framework, your asset may be less portable than you think.

These are not theoretical annoyances. They are the exact problems that surface during diligence, when a buyer asks how quickly the company can onboard a new team, continue development, and prove that the product is not dependent on one external actor.

What to ask a build partner before signing

Use questions that reveal both the contract structure and the operating model:

• Will the repo live in our organization from day one?
• What is assigned to us, and what is merely licensed?
• What background IP, templates, or frameworks will remain yours?
• Which open-source components do you use, and how are they tracked?
• How do you document architecture, deployment, and key decisions?
• What does handover include at the end of the engagement?
• Can you show a past handover where another team took over successfully?
• How do you review AI-assisted changes before merge?
• What evidence will we have of authorship, review, and approval?

If a partner cannot answer those questions cleanly, they are asking you to trust process you have not seen. For a founder, that is not enough.

How we handle ownership at Better Software

We structure engagements so ownership is not an afterthought. The codebase lives in the customer’s repo from day one. The starting template is public and MIT-licensed, so the foundation is inspectable rather than hidden. Our Engineering Handbook is public, and it defines how every AI-assisted change gets senior review. The goal is simple: if the engagement ended tomorrow, the customer would keep the asset and keep building.

That is what “the codebase is yours” means in practice. Not a clause in isolation. A structure that supports legal transfer, operational continuity, and provable authorship.

FAQ

Who owns software code if there is no contract?

Usually the author does. If there is no written agreement assigning rights, the payer often does not automatically own the code, even if they commissioned it.

Who owns the copyright in a work for hire?

In a valid work-for-hire arrangement, the employer or commissioning party may be treated as the legal author. But the doctrine is narrow, especially for contractors, so the label alone is not enough. The contract must actually fit the legal requirements.

Does ChatGPT or Claude own the code it writes?

No. The practical issue is not whether the tool “owns” the code, but whether the resulting output has a clear human author and a defensible record of human control, review, and acceptance.

What should a code handover include?

At minimum: the source repo, documentation, architecture notes, test suite, build and deployment instructions, environment setup, cloud and tooling access, secrets transfer process, and a walkthrough of any vendor-specific dependencies.

Paying for software is the beginning of the ownership test, not the end. The founders who get this right do not just buy code; they acquire an asset they can prove, operate, and defend.