Most deep tech startups move fast. You hire a friend from grad school. You pull in a contractor to clean up the code. You ask a designer on Upwork to “just make a quick UI.” You bring on a founding engineer and promise equity later.
And in all that motion, a quiet problem shows up.
Who owns what they build?
If the answer is not written down in a clean, signed IP agreement, you are taking a real risk. Not a “lawyer risk.” A company risk.
Because deep tech value is not only your product. It is the new method you found. The model you trained. The robot motion plan you tuned for weeks. The sensor fusion trick that finally works in the real world. The tiny piece of code that turns a demo into a moat.
If any part of that comes from someone who does not clearly assign their IP to the company, you can end up with a hole in your foundation. And holes show up at the worst time: when an investor asks due diligence questions, when you try to sell, when a key person leaves, or when a big customer wants to see your contracts.
This article is about the IP agreements every deep tech startup needs for employees and contractors, and how to use them in real life. No drama. No fear. Just clear steps you can take now, so your work stays yours.
And if you want help doing this the right way—patent plan, filings, and clean IP setup—Tran.vc invests up to $50,000 worth of in-kind patent and IP services for deep tech founders. You can apply anytime here: https://www.tran.vc/apply-now-form/
Contractor and Employee IP Agreements Every Deep Tech Startup Needs
Why this matters more in deep tech
Deep tech startups do not win by moving faster than everyone else for a month. They win by building something others cannot copy for years. That “cannot copy” part often lives inside your methods, your code, your models, and your design choices. Those things are not always visible in the product demo, but they are the real value.
If you do not lock down IP ownership early, you can end up with a company that looks strong on the surface but is weak underneath. One missing signature can turn into a deal delay, a pricing cut in a round, or a hard “no” from an acquirer. This is not rare. It is common, and it is preventable.
Tran.vc helps founders prevent this exact problem by pairing patent strategy with clean IP foundations from day one. If you want that support, you can apply anytime here: https://www.tran.vc/apply-now-form/
The simple idea behind IP agreements
An IP agreement is a written promise that says, “Anything you create for the company belongs to the company.” It also explains what “create” means, what “for the company” means, and what happens when someone leaves. Without that clarity, people fill in the blanks with their own assumptions.
Assumptions are where startups get hurt. The founder assumes the company owns the work because it was paid for. The contractor assumes they own it because they wrote it. The employee assumes they can reuse pieces on their next job. None of those views is safe unless the agreement is clear and signed.
What this article will help you do
You will learn how to separate employee IP agreements from contractor IP agreements, because they are not the same. You will also learn what clauses matter most for deep tech work, and how to handle real situations like open-source use, side projects, and research work.
The goal is not to turn you into a lawyer. The goal is to help you run your startup like a careful builder. You want a clean chain of ownership so investors, customers, and future hires can trust what you have built.
The core distinction you must understand
Employees and contractors are treated differently
The biggest mistake founders make is thinking “work is work.” In reality, the law often treats employees and contractors in very different ways. That difference changes who owns the output by default, and it changes what your paperwork must say.
In many places, employee work created within the job is more likely to be treated as company-owned, especially when it is clearly tied to the employee’s role and company resources. Even then, you still want strong agreements, because “more likely” is not the same as “guaranteed.”
Contractor work is often the opposite. If you hire a contractor and you do not have a clear written assignment, the contractor may own the work by default. You may receive a right to use it, but not full ownership. For deep tech, “a right to use” is not good enough when you are trying to build a moat.
Why this difference matters in real startup life
Imagine you hire a contractor to build your first robotics control stack. You pay them. They deliver code. You ship a demo. Then a seed investor asks, “Do you fully own this code, including all rights to modify and patent anything inside it?”
If your answer is, “We paid for it,” that does not close the gap. The investor will ask for the contract. If the contract does not include a clear IP assignment, the investor may treat your core asset as uncertain.
That uncertainty can lead to a forced cleanup project. You may need to track down the contractor months later, negotiate new terms, or even pay again to fix the chain of title. If they refuse, you may have to rebuild. That is a painful way to learn this lesson.
How to think about “ownership” in one clean sentence
Here is a simple rule to guide your thinking. For employees, you are confirming and strengthening ownership that may already lean toward the company. For contractors, you are creating ownership that may not exist at all unless you write it into the deal.
That is why you should never use the same one-page template for both. The risk profile is different, the wording needs to be different, and the “edge cases” show up in different places.
What an employee IP agreement really needs
The invention assignment must be clear and broad
An employee IP agreement should clearly say that inventions, code, designs, methods, improvements, and other work created as part of the job belong to the company. Deep tech teams often create things that are hard to name. The agreement should not only cover “software” or “patents.” It should cover the full range of output.
This is important because a lot of deep tech value starts as “not a patent yet.” It starts as a messy notebook, a test script, a training pipeline, or a tuning trick that only one engineer knows. You want those early forms covered, because they often become the patent story later.
Strong agreements also reduce confusion inside the team. People can still feel proud of what they built, but ownership is not a question. The company owns it, and the company can protect it.
The scope should connect to the job, not only the office
A common misunderstanding is that work belongs to the company only if it was made in the office or during office hours. Deep tech does not work like that. Your best engineer may solve a hard problem at midnight on a laptop at home. That solution still may be part of their job.
Your agreement should tie ownership to the role, the company’s business, and the tasks they are paid to do. It should not rely on the idea of a physical workplace. Modern teams are remote, and time is flexible. The agreement must match reality.
At the same time, you must be careful not to write something so aggressive that it scares good candidates. The best approach is clear, fair language that focuses on work connected to the company and its plans.
Handling side projects without turning into the “idea police”
Employees often have side projects. Some are harmless and healthy, like a small app or a hobby robot. Some are risky, like a tool that overlaps with your roadmap. If you ban all side work, you may lose strong talent. If you ignore side work, you may end up in a fight later.
A good employee agreement usually asks the employee to disclose side projects that relate to the company’s field. This is not about control. It is about clarity. If a side project overlaps, you can talk early and avoid pain later.
Many startups use a simple disclosure process. The employee lists side projects at hiring time, and updates the list if something changes. The company then confirms in writing what is excluded from the company’s claim. This keeps trust high and confusion low.
The duty to help with patents and paperwork later
Deep tech startups often file patents after the first prototypes. That means you may need an employee to sign inventor documents even after they leave. If your agreement does not cover this, you can end up chasing people who have moved on, changed emails, or are upset.
A strong employee IP agreement includes a duty to cooperate. It says the employee will help with patent filings and ownership paperwork, even after the employment ends. It also says the company will cover reasonable costs and time.
This clause is not about forcing someone to work for free. It is about making sure the company can protect the inventions that were created during their job. Investors look for this because they want to know the patent process will not get stuck.
What a contractor IP agreement really needs
“Paying for work” is not the same as “owning work”
Contractors are often hired with simple email threads: “Can you build X? We’ll pay Y.” That is fine for quick tasks that do not touch your core. But in deep tech, contractors often touch the core early, because you need speed.
When a contractor writes code, designs hardware, creates data pipelines, or builds models, they are creating IP. Without a written assignment, you may only be buying a service, not the rights. That is why contractor paperwork must be more direct than employee paperwork.
The contract should say that the contractor assigns all rights to the company, including the right to file patents. It should also say the assignment happens as the work is created, not months later. This avoids gaps in ownership.
Work-for-hire language is not enough in many cases
Some founders think that adding the words “work made for hire” solves everything. In reality, that phrase may not cover all types of work, and it may not apply in all places or all situations. It is helpful, but it should not be your only tool.
A safer structure is to use both concepts: first, state that the work is intended as work-for-hire where allowed, and second, include an invention assignment clause that transfers rights to the company regardless. This belt-and-suspenders approach is common in serious startup contracts.
This matters even more when contractors contribute inventions that could become patents. Patent rights are sensitive. Investors do not want to wonder whether a contractor might later claim ownership.
Contractors often reuse tools, and you must manage that
Contractors may have their own libraries, templates, scripts, or design blocks they use across clients. That is normal. The risk is when they reuse something that becomes part of your core stack and then claim it is their “background IP.”
A good contractor agreement separates “background IP” from “project IP.” Background IP is what they already had before the job. Project IP is what they create for you during the job. The contract should say that project IP is assigned to your company.
If the contractor must bring background IP into your project, the contract should require them to list it and grant you a clear license to use it. That way, you are not surprised later by a hidden dependency that you do not control.
You must control who else touches your work
Contractors sometimes subcontract. They bring in a friend to help, or they hire a junior dev to do parts of the task. If you do not know this is happening, you may end up with IP created by someone who never signed anything.
Your contractor agreement should clearly say that subcontracting is not allowed without written approval. If you allow it, you should require that the subcontractor signs the same IP assignment and confidentiality terms.
This is not about being difficult. It is about keeping the chain of ownership clean. When the company grows, nobody wants to find out that a key module was written by an unknown person who cannot be reached.
The deep tech edge cases that cause the most pain
Open source is powerful, but it can create ownership and license traps
Deep tech teams use open source all the time. That is good. But some open-source licenses can require you to share your own code if you distribute a product built on top of it. That can be fine for some businesses and terrible for others.
Your IP agreements should not pretend open source does not exist. Instead, they should require that employees and contractors follow your open-source policy. If you do not have one, create a simple version now.
At minimum, require that any new open-source dependencies are approved, documented, and reviewed. This is not busywork. It is insurance. You want to know what you are building on so you can avoid surprises during enterprise sales or investment due diligence.
Data rights and model rights are not always covered by “code” language
AI startups often focus on code, but value may live in data, labels, prompts, evaluation sets, synthetic data pipelines, and training runs. Robotics teams may have logs, maps, calibration files, and test footage. These assets can be as valuable as the model itself.
Your agreements should explicitly include data-related assets. If a contractor labels data or creates a dataset, you want to own the output. If an employee creates a novel way to collect data, you want the company to own that method too.
This is also where confidentiality terms matter. A person can walk away with a dataset in their personal drive if you do not set expectations and controls early. The agreement is one piece. Your internal process is the other piece.
Research roots can blur the line between the lab and the company
Many deep tech startups start inside universities or research labs. That is exciting, but it brings special IP risks. If founders developed key work while under university obligations, there may be institutional claims. If a contractor is also a grad student, their lab may have policies too.
Your employee and contractor agreements cannot override a university’s rights. But they can help you surface conflicts early. They can require disclosure of prior obligations and confirm what the person has the right to assign.
If your startup has research roots, it is worth treating IP cleanup as a top priority. This is one of the places Tran.vc often helps founders, because patent strategy and ownership clarity need to move together. If you want help, apply anytime: https://www.tran.vc/apply-now-form/