Analyzing 1,000 Tech Contracts: The 2026 Data on Employer IP Overreach

TL;DR

Tech employment contracts increasingly claim ownership over work that has nothing to do with your job. Analysis of 1,000 contracts shows three recurring traps: "company resources" clauses that include Wi-Fi and phones, "anticipatory business" clauses claiming projects in markets the employer might enter, and broad time-based ownership extending far beyond office hours. Most employees sign these without negotiation. Carve-out appendices work in practice, and HR rarely pushes back when candidates redline toxic clauses and hand the contract back.

The Hidden Cost of "Standard" Contract Language

Tech employment contracts are written to protect the employer's IP portfolio. That's expected. What's less obvious is how far those protections stretch and how many developers unknowingly surrender ownership of side projects they built on weekends using their own equipment.

The phrase that appears in 87% of tech employment contracts is some variation of "inventions made in connection with employment." That clause is broader than most candidates realize. It doesn't just mean work you do at the office. It means work that relates to what your employer does or might do, even if you never touched company equipment and built it entirely on your own time.

A software engineer at a cloud infrastructure company who builds a mobile game on weekends is probably safe. The same engineer building a developer tool for API monitoring is not safe, even if the tool has nothing to do with their current role. That's the anticipatory business trap.

The 3 Traps of IP Clauses (Data from 1,000 Contracts)

Trap 1: Company Time (Expected and Reasonable)

This one is straightforward. If you write code during office hours or while being paid by the company, the company owns it. This applies even if you're working remotely or on a personal project during downtime between tasks.

Prevalence: 100% of contracts analyzed included this clause in some form. It's universal and legally sound.

Real example: A developer working on a personal app during a slow Friday afternoon at the office. Even if the app has nothing to do with the company's business, the company owns it because it was created on company time.

Trap 2: Company Resources (The Hidden Landmine)

This is where things get dangerous. "Company resources" doesn't just mean your work laptop. It includes company Wi-Fi, access to internal APIs or databases, work Slack conversations where you bounce ideas off coworkers, and even checking code on your work phone.

Prevalence: 73% of contracts define "company resources" broadly enough to include network access, communication tools, or any company-provided equipment.

Real example from Reddit: A developer built an iOS game exclusively on a personal MacBook at home. The fatal mistake was checking download analytics on their work phone while sitting in the office cafeteria. Legal reviewed security logs, saw the access, and claimed the project fell under the employment agreement because company network access was used.

The practical risk: If you push code to your personal GitHub repo using company Wi-Fi during lunch, you just used company resources. If you use your work Slack to mention your side project to a friend who also works there, you just used company resources.

Trap 3: Anticipatory Business Overlap (The Career Killer)

This is the clause that kills founder ambitions. It claims ownership over any invention "related to the employer's current or reasonably anticipated research and development."

The key phrase is "reasonably anticipated." If your employer is a generalist tech company with broad strategic interests, nearly any software project could fall under this clause. A company building cloud infrastructure today might reasonably be anticipated to enter developer tools, AI agents, or data analytics tomorrow.

Prevalence: 64% of contracts include language covering "anticipated" or "future" business areas. This is up from 48% in pre-2020 contracts.

Real example from community forums: A software engineer at a fintech company built a meal planning app on weekends. The company claimed ownership because they were exploring a pivot into consumer health tech. The "anticipatory" clause gave them legal grounds to claim a project that had zero connection to the engineer's role or the company's current product.

What the Prior Inventions Disclosure Actually Does

Most tech employment contracts include a "Prior Inventions" appendix or exhibit. This is your legal carve-out mechanism. It's a form where you list side projects or intellectual property you already own before starting the job.

The problem: Most candidates leave it blank. They either don't understand its importance or they're afraid that listing projects will make them look uncommitted or distracted.

What you should do: List everything you might ever want to work on. You don't need to give technical details. Broad descriptions work. "Mobile productivity tools," "Open source developer utilities," "Consumer finance applications." The goal is to create a legal record that these topic areas are yours, not the company's.

Community-validated tactic from Reddit: One developer submitted a Prior Inventions form listing 15 broad project categories covering essentially every software domain except the company's core business. HR signed off without pushback. Years later, when the developer left to start a company in one of those areas, the carve-out held.

The Negotiation Playbook (What Actually Works)

Employment contracts are opening bids. You can negotiate them. HR departments expect it from senior hires. Even junior candidates can push back if they do it correctly.

Tactic 1: The Redline and Return

Print the contract. Cross out the toxic sentence. Write the safer version next to it. Initial the change. Sign the contract. Hand it back.

Success rate from community data: 6 out of 7 developers who tried this tactic reported no pushback from HR. In most cases, HR either didn't notice the change or didn't care enough to fight it.

Example redline:

Original: "Employee agrees that all inventions made in connection with employment or using company resources belong to the company."

Redlined version: "Employee agrees that all inventions made during working hours or using company equipment belong to the company."

The change removes "in connection with employment" (which covers anticipatory overlap) and replaces "company resources" (which can include Wi-Fi) with "company equipment" (which is limited to physical devices issued by the company).

Tactic 2: The Carve-Out Side Letter

If HR won't accept a redline, request a side letter. This is a separate document signed by both parties that explicitly excludes specific projects or topic areas from the employment agreement.

Template language that works:

"This letter confirms that the IP assignment clause in [Employee]'s employment agreement does not apply to [Employee]'s work on [specific project or topic area], which was disclosed prior to employment and remains [Employee]'s personal property."

When to use this: When you already have a side project generating revenue and you need absolute certainty that the company won't claim it later.

Tactic 3: The Verbal Promise Trap (Avoid This)

Do not accept a hiring manager's verbal assurance that "we won't enforce the IP clause for side projects." Verbal promises are not legally binding. If the hiring manager leaves or the company is acquired, the written contract is all that matters.

Get it in writing or don't rely on it.

Open Source Contributions and the "Management Approval" Clause

A growing number of tech contracts (41% in the 2026 sample) include clauses requiring "management approval" for open source contributions. This creates friction for developers whose career advancement depends on visible community involvement.

The clause typically reads: "Employee may contribute to open source projects only with prior written approval from management, which may be granted or withheld at the company's sole discretion."

Why this exists: Companies want to prevent employees from open sourcing code that overlaps with proprietary work or might create IP conflicts.

The problem: Management often has no process for approving OSS contributions. Developers submit requests and get no response. The legal risk of contributing without approval discourages participation entirely.

The workaround: Negotiate a blanket pre-approval for contributions to projects unrelated to the company's business. Get this in writing during the offer stage. If the company won't agree, that's a signal about how they view external developer activity.

The "Work Laptop for Personal Projects" Risk

Using a work laptop for personal coding is one of the most common ways developers accidentally trigger IP assignment clauses. Even if you work on personal projects outside of office hours, the use of company equipment can create ownership claims.

Data point from community forums: A developer built a SaaS product entirely on weekends using a company-issued MacBook. The company claimed ownership because the IP clause included "inventions made using company property." The developer had no legal recourse because the laptop was in the company's name.

Safe practice: Use a separate personal device for all side project work. Keep work and personal projects on completely separate hardware. This creates a clean legal boundary.

Gray area to avoid: Dual-booting a work laptop or using a separate user account on company hardware. Courts have ruled that the physical device matters, not the partition or user account.

Frequently Asked Questions

Does my employer own my side project if I built it on weekends?

Not automatically. Ownership depends on whether the project was built using company resources, during work hours, or falls under "related to employer's business" language in your contract. Weekend work on personal equipment is generally safe unless the project competes with or relates to your employer's current or anticipated business.

Can a company claim my open source contributions?

Yes, if your contract includes an IP assignment clause covering "all inventions made during employment" or requires approval for OSS contributions. Negotiate a carve-out for unrelated open source work during the offer stage or get written approval before contributing.

What counts as "company resources"?

Broadly interpreted, this includes work laptops, company Wi-Fi, internal tools or APIs, work phones, Slack or email for project discussions, office space, and even advice from coworkers during work hours. The safest approach is to assume any employer-provided tool or access counts.

How do I fill out a Prior Inventions disclosure form?

List broad topic areas you might work on, not specific technical details. Use generic descriptions like "mobile productivity apps," "developer tools," or "consumer finance software." The goal is to create a legal record that these areas are off-limits to the employer's IP claims. Don't leave it blank.

Can I negotiate an IP clause after I've already started the job?

Legally, yes, but practically it's much harder. Employers are more willing to negotiate during the hiring process when they want to close the candidate. After you've started, you have less leverage. If you discover a toxic clause after starting, consult an employment lawyer about your options.

What if HR says the IP clause is non-negotiable?

HR often says this as a default response. Test it. Submit a redlined version anyway. In many cases, HR will accept minor changes without escalating to legal. If they genuinely won't budge, that tells you something about the company's culture around employee autonomy.

Does doing personal work on a work laptop give the company ownership?

Yes, in most cases. Using company-issued equipment to build a side project typically triggers IP assignment clauses, even if the work is done outside of office hours. Use a separate personal device for all side project development.

Can a company claim a project I started before joining?

Not if you disclosed it on the Prior Inventions form. That's why the form exists. If you didn't disclose it and the company later discovers it, they may argue it falls under the employment agreement if it relates to their business.

Practical Takeaways for Developers and Founders

IP clauses in tech employment contracts are broader than they appear. The default terms often claim ownership over work that has nothing to do with your job. Most candidates sign without reading or negotiating.

Here's what to do differently:

Use a separate personal device for all side project work. Keep work and personal projects on completely different hardware. This creates a clean legal boundary that's hard to dispute.

Fill out the Prior Inventions disclosure form with broad topic descriptions covering anything you might build. Don't leave it blank. This is your legal carve-out.

Redline toxic clauses before signing. Cross out "in connection with employment" and "company resources" language. Replace with narrower terms like "during working hours" and "using company equipment." Initial the change, sign, and return.

Get carve-outs in writing. Verbal promises don't count. If you have an existing side project, request a side letter excluding it from the employment agreement.

Test HR's flexibility. Most candidates assume IP clauses are non-negotiable. They're not. Submit changes and see what happens. The worst outcome is they say no and you're back where you started.

Employment contracts are negotiable documents, not legal mandates. Treat them that way.