Paying for code does not mean you own it. If an agency, an offshore shop, a freelancer, or even a co-founder wrote part of your product without a signed present-tense assignment, the rights may still sit with them, not your company. This is the quiet thing that stalls a round at the term-sheet stage, and the fix is cheap before the round and miserable during it. Sort out your chain of title now, while the people who wrote your code still answer your messages.
I get pulled into this more than I would like, almost always at the worst moment. A founder has a term sheet, the product works, growth looks real, and then the investor's diligence checklist asks one boring question: can you show that the company owns all of its code. The founder assumes yes, because they paid for everything. Then we start pulling the thread and the answer turns out to be "mostly," which in this context means "no."
Paying an invoice is not the same as owning the work
Here is the part that catches non-technical founders off guard. In the US, the person who writes a piece of code owns it by default, even if you paid them to write it. Paying the invoice settles the bill. It does not transfer the copyright. The only thing that moves ownership to your company is a signed agreement that says, in present tense, "I assign these rights to the company." Promises to assign, or work-for-hire language that does not actually apply to the situation, leave a gap.
I am not your lawyer, and you should have one read your specific agreements. But you do not need a law degree to see the pattern, and the pattern is consistent. The code that powers your company was very likely written by a mix of people who were never properly tied to the company: the agency that built the first version, the offshore team that has been shipping for a year, the freelancer you found on a marketplace and paid through a payment app, the technical friend who helped on weekends before there was a company to assign anything to. Each one is a small hole in the hull. Individually they look harmless. Together they are why an investor's lawyer says "we need to pause."
Where the chain of title actually breaks
In the messes I have helped untangle, the gaps cluster in a few predictable places.
The first is the agency or contract shop that built your MVP. A lot of standard agency contracts assign the deliverable to you but quietly keep the "background IP," meaning the reusable libraries, scaffolding, and internal tools the agency drops into every client build. So you own the parts that are unique to you and license the parts that make it run. That is fine until an acquirer asks whether you can ship the product without the agency's permission, and the honest answer is no. This is the same lack of reading that I wrote about in the agency invoice nobody reads. The contract has the same blind spot as the invoice.
The second is the offshore team, especially when you engage them as a vendor rather than as employees. The assignment, if it exists, runs from the individual developers to their employer, and from their employer to you only if your contract with that employer says so and the chain underneath it holds. If you are managing that relationship loosely, which is common when you are not technical and trying to run an offshore team, nobody has ever checked that the paperwork matches the code. The developers who actually typed it may have signed nothing that names your company at all.
The third is the people closest to you: co-founders and early helpers. A co-founder who wrote the original prototype before incorporation owns that prototype personally until they assign it to the company. Most founders never do this paperwork because it feels absurd to sign a contract with yourself. Investors do not find it absurd. A founder breakup with unassigned code is one of the few things that can kill a company outright, because the person walking out the door may legally own a piece of the product.
AI-written code added a new question, not a new escape hatch
In 2026 there is a fresh wrinkle. A growing share of early product code was generated by AI coding tools, and that raises two questions diligence teams now ask out loud. Who owns output that a machine produced, and what did that machine borrow to produce it. The honest state of things is unsettled, but the practical exposure is real: code that closely reproduces a copyleft open-source project can drag license obligations into your proprietary codebase, and you will not know it is there because no human chose to include it.
This is the ownership cousin of a point I made in your AI-built MVP is a draft, not a product. The risk is not that AI wrote your code. The risk is that nobody can tell you what is in it or where it came from. An AI tool will not sign an assignment, and it cannot vouch for the provenance of what it produced. That does not make the code unusable. It makes provenance something a person on your side has to actually check, rather than assume.
What a clean chain of title looks like
Strip away the legal vocabulary and the standard is simple to state. Every person and every entity that contributed code, design, or other work product to your company has signed something, in present tense, assigning those rights to the company. Founders, employees, contractors, agencies, the offshore vendor, the weekend helper. No exceptions and no "we will get to it."
For employees this is usually handled by the invention-assignment clause in their offer paperwork, which is why employee-written code is rarely the problem. The problems live in the relationships founders treat as transactions: you paid a vendor, the vendor delivered, everyone moved on, and nobody ever made the rights follow the money. The same instinct that makes keeping your first engineer a contractor attractive is the instinct that leaves the assignment unsigned, because a contractor feels lighter-weight than an employee. Lighter-weight is exactly the problem here.
Fix it cold, not under deal pressure
The reason to handle this now is leverage. Today, the agency wants your repeat business, the offshore team wants the next contract, the freelancer wants a reference, and the co-founder is still your co-founder. Everyone has a reason to sign a clean assignment and almost no reason to refuse. A confirmatory assignment that papers over a past gap is a short, friendly document when there is nothing at stake.
Now run the same conversation during diligence. The agency you stopped using a year ago has no incentive to do you a favor on a tight timeline. The freelancer you found on a marketplace has changed their handle and gone quiet. The co-founder you parted ways with badly is the one whose signature you suddenly need. The document is the same. The price went from a favor to a hostage negotiation, and the clock is the investor's, not yours.
So the work is unglamorous and worth doing on a calm afternoon. List everyone who ever touched the codebase. For each one, find the signed assignment. Where it is missing, get a confirmatory assignment signed while the relationship is still warm. For the AI-generated portions, have someone competent check what open-source licenses are actually present in your dependencies and your generated code, and clear or replace anything that does not belong. This is part of what a senior set of eyes looks for in a codebase teardown: not just whether the architecture is sound, but whether you can prove the company owns what it is built on.
None of this requires a full-time CTO. It requires someone who has sat on the wrong side of a diligence call and knows which gaps actually stop a deal versus which ones a lawyer waves through. If you are heading toward a raise and you are not certain you could answer the ownership question cleanly, that is a good reason to book a call before the term sheet arrives, not after.
Frequently asked questions
If I paid a contractor to build my product, don't I automatically own it?
No. In the US, the author of the code owns it by default, and paying the invoice does not transfer that ownership. Rights move to your company only through a signed assignment with present-tense language. Without it, you have paid for work you may not fully own, which is exactly what diligence is designed to catch.
What is a "chain of title" for code and why do investors care?
Chain of title is the unbroken trail of signed assignments showing that every contribution to your codebase, from founders to the offshore vendor, was legally transferred to the company. Investors treat it as a threshold issue. If the chain is broken, the company may not own its core asset, and most institutional investors will not put capital into assets a company cannot prove it owns.
Does AI-generated code create IP ownership problems?
It can. The ownership of purely machine-generated output is unsettled, and AI tools can reproduce open-source code that carries license obligations you never agreed to take on. The practical move is not to avoid AI, but to have someone check the provenance and licenses in your codebase, since the tool cannot sign an assignment or vouch for what it borrowed.
How do I fix a missing assignment after the fact?
You get a confirmatory assignment: a short document where the past contributor assigns the relevant rights to the company, signed now to cover work done earlier. The key is to do it while the relationship is still friendly. The same signature is easy to get today and very hard to get under deal pressure, when the other party knows you need it.
When should I sort out code ownership?
Before you need it. The cheap, low-drama time is during normal operations, when contributors still want your business or your goodwill. The expensive time is mid-diligence, when a missing signature can stall or kill a round and the people you need have no reason to move quickly. Treat it as routine hygiene, not a fundraising task.