IP in an IT product: where teams lose rights
How to check rights to code, interface work, brand assets, and third-party components before investment, licensing, or a dispute.
An IT product can be ready for the market and still be legally split into layers: employee code, contractor modules, open source, studio design, a founder-owned domain, marketing copy, and a brand that has not been cleared. For an investor, buyer, or enterprise customer, the working product is only part of the question. The chain of rights matters.
Check who created each layer
Separate the product into codebase, UI/UX, content, databases, brand, domains, accounts, and documentation. For each layer, answer: who authored it, how it was transferred to the company, where the evidence is stored, and whether there are limits on use or transfer.
Early contractors and co-founders deserve special attention. If work was done before company formation or without a contract, rights may remain with the author or become disputed. That does not always block the product, but it changes due diligence and negotiations.
Do not confuse access with ownership
Access to a repository, Figma file, domain, or cloud account does not transfer exclusive rights. A legal review needs a document: employment agreement, work assignment, development contract, acceptance act, assignment, license, or another rights-transfer mechanism.
If a contractor used its own libraries, templates, or prior work, the contract should separate transferred deliverables from pre-existing IP. Otherwise the company may receive a product it cannot freely sell, license, or contribute to a transaction.
Review open source separately
An open-source component list is not only a technical artifact. Licenses can affect distribution, derivative works, notices, attribution, and commercial use. The risk depends on the exact license, product architecture, and delivery model.
Record the package name, version, license, where it is used, and who owns updates. This helps avoid rebuilding the analysis from scratch when a customer or investor asks for a software bill of materials.
Brand and interface need evidence
Product name, logo, domain, and visual system should be reviewed separately from code. Check who owns the domain, who filed or will file the trademark, which classes matter, who created the design, and whether transfer documents exist.
For interface work, keep source files, versions, assignment correspondence, and author contracts. In a dispute or deal, the final screen is not enough; the company needs evidence that it controls the result.
When to run an IP review
- before an investment round or M&A;
- before licensing the product to a large customer;
- when a contractor, former employee, or co-founder dispute appears;
- when entering a new market under the same brand;
- when a questionable open-source dependency is found.
An IP review does not mean claims cannot arise. It shows where rights are documented, where a document is missing, and where the answer depends on creation facts, contract terms, and jurisdiction.