A partner helps shape your product. An agency builds the brand. A contractor writes code that becomes central to your business.
Everyone is moving quickly. The work is good. The relationship feels solid.
Then someone asks a simple question: Who owns what you built together?
If the answer is “we’ll figure it out later,” you may have a problem. Paying for work does not automatically mean your company owns it. And a friendly working relationship is not a substitute for clear terms.
The time to decide ownership is before the work begins, not when the relationship changes.
Start by separating what each side brings
Before discussing what the project creates, make a list of what each party already has.
That might include software, designs, templates, processes, brand assets, data, documentation, or specialized know-how. These are often called background IP: materials a party developed or owned before the collaboration.
The list matters because the project may rely on those materials without transferring ownership of them. A partner may let your company use a pre-existing tool to complete the work, for example, while keeping ownership of that tool.
Write down the boundary:
- What does each party bring into the project?
- What can the other party use, and for what purpose?
- Can that use continue after the project ends?
- Can the materials be modified, sublicensed, or used in another product?
If the answers are vague, the parties may later disagree about whether something was an existing tool or a new deliverable.
Define what the project creates
Next, describe the work the collaboration is expected to produce. Be specific enough that the contract reflects the actual project.
Depending on the relationship, the deliverables might include source code, product designs, written content, prototypes, documentation, inventions, or improvements to existing tools.
Then decide who owns each category, and what rights the other party needs to do its job.
One straightforward arrangement is for each party to keep its background IP while the company owns the agreed project deliverables. The company can then grant the partner a limited right to use company materials only to perform the work.
That may not fit every deal. A partner may need to retain certain reusable tools or methods. A co-builder may expect rights to use the results. Those terms can be negotiated. The key is to state them clearly, instead of relying on assumptions.
Do not rely on “work made for hire”
Founders often hear that contractor work can be treated as “work made for hire.” It is not a catch-all ownership switch.
Under U.S. copyright law, the rules depend on the type of work and the relationship. Commissioned work qualifies only in certain situations and generally requires a signed agreement that says it is work made for hire. For many contractor projects, that label alone may not transfer ownership.
A signed copyright transfer is a separate and important step. Federal law generally requires a written, signed transfer of copyright ownership. See 17 U.S.C. § 204 and the Copyright Office’s guide to works made for hire.
The practical takeaway: use clear assignment language where the company is meant to own the work. Do not assume payment, delivery, or a “work for hire” heading does the job.
Get the whole contributor chain covered
A contract with an agency does not automatically resolve who owns the work of the agency’s employees, freelancers, or subcontractors.
Ask who will actually contribute. Then make sure the agreement requires the agency to obtain the necessary rights from those contributors and pass them through to your company. The same applies when a partner brings in its own subcontractor.
For each contributor, confirm that the paperwork addresses:
- Ownership of project work and inventions
- Rights to use or transfer pre-existing materials
- Disclosure of third-party materials and their license terms
- Signatures and cooperation needed to document ownership later
This is especially important when a person’s contribution could become central to the product. If the company does not have the right to use, modify, or commercialize a key component, the business may be dependent on someone else’s permission.
Be careful with co-created work
“Let’s build it together” sounds simple. Legally, it can create complicated ownership questions.
Copyright law recognizes joint authorship, and patent law has its own rules for joint inventors. For patents, unless the co-owners agree otherwise, each joint owner may generally use or license the invention without the other owner’s consent or accounting.
That may be acceptable in some collaborations. In others, it can create a serious business headache: one party might license or commercialize shared IP without the other’s approval.
If the parties intend one company to own the project IP, document that arrangement and make sure the necessary rights are assigned. If they intend shared ownership, decide how the parties will handle licensing, commercialization, enforcement, costs, and future improvements.
“Jointly owned” is not a complete plan. It is the beginning of a list of questions.
Protect confidential information as carefully as ownership
A contract can say that information is confidential. But your company also needs sensible practices for keeping it that way.
Trade secret protection depends, in part, on taking reasonable steps to preserve secrecy.
Share sensitive materials only with people who need them. Make sure contractors and approved subcontractors have confidentiality obligations. Set rules for storage, access, return, and deletion when the work ends.
Use an NDA for early discussions where appropriate, but do not assume an NDA defines who owns the project’s results. That belongs in the development or services agreement.
Plan for the end of the relationship
Good agreements do not assume a partnership will last forever. They make the off-ramp clear.
If the engagement ends, what work must be delivered? Who keeps copies? What happens to credentials, source files, prototypes, and unfinished materials? Can either party keep using the other’s background IP? Which licenses survive?
A clean handoff is not just a folder of final files. It may include editable working files, documentation, access details, and the rights needed to use or maintain the work. Patent assignments may also need to be recorded; the USPTO explains the role of assignment records.
Put those expectations in writing before the project gets busy. It is much easier to agree on a handoff while everyone is aligned than after a dispute starts.
A quick ownership check before work starts
Before signing a partnership, agency, or contractor agreement, ask:
- What IP does each party already own?
- What exactly will the project create?
- Who owns each deliverable, invention, and improvement?
- What third-party materials or subcontractors are involved?
- What licenses does each party need during the project, and afterward?
- What happens to files, access, and unfinished work if the relationship ends?
The answers do not have to be complicated. They do have to be clear enough that both sides can act on them.
Put the terms in place while the relationship is good
Founders do not need to turn every collaboration into a courtroom exercise. They do need to avoid leaving ownership to memory, goodwill, or invoice history.
A fractional general counsel can help identify what needs to be owned, what can remain with the partner, and what licenses make the project workable. That includes reviewing the contributor chain, aligning the contract with how the work will actually happen, and spotting gaps before they become blockers.
The best time to answer “who owns what?” is before the first deliverable arrives. The next best time is now, while the people who built it together are still willing to talk. Talk with The Chief Counsel about putting clear terms around your next partnership.