Can My Employer Own Everything I Create? Your Rights as an Employee

If you've ever written code at 10pm on your personal laptop and wondered whether your company has a claim to it, you're not alone. This question is one of the most searched, most misunderstood, and most anxiety-inducing corners of employment law — especially for developers, designers, and founders with a day job.

The short answer: it depends almost entirely on your contract, not the clock.

• Default law gives you copyright in work you create independently. But most tech/creative employment contracts override this with sweeping IP assignment clauses.
• "During the term of employment" language can cover weekend projects — even on your own laptop.
• Using a work device or work network on a personal project is the single fastest way to compromise your ownership.
• Pre-existing projects must be listed on an Exhibit A / Schedule 1 before you sign — or they're at risk.
• A carve-out amendment is possible to negotiate. Most employers will agree if you approach it correctly.

What the Law Actually Says (Before Your Contract Overrides It)

The statutory default in both the UK and US gives copyright ownership to the creator — you. Under the UK Copyright, Designs and Patents Act 1988 (Section 11), works created by employees in the "course of their employment" belong to the employer. Under US work-made-for-hire doctrine, a similar principle applies to works prepared within the scope of employment.

Both frameworks hinge on one critical phrase: scope of employment or course of employment. Courts apply a multi-factor test to determine whether something qualifies, checking whether:

• The work was the type of activity the employee was hired to perform
• The creation happened substantially within authorised work hours and space
• The work was at least partly motivated by serving the employer

A video game built by someone hired as a financial analyst probably fails this test. Code written by a senior software engineer at a tech company, in the same language they use daily, is a much harder case — even if it was written at midnight.

The problem is that most employment contracts don't rely on these statutory defaults at all.

The Contract Is the Real Battleground

Modern tech and creative employer contracts almost universally contain broad IP assignment clauses that expand far beyond what the law requires by default. The phrase to watch for is something like:

"Employee hereby assigns to Company all intellectual property conceived, developed, or created during the term of employment, whether or not created during business hours or using Company equipment."

That clause, if signed, effectively strips you of rights to anything you create while employed — regardless of when or where. Courts in the UK and US have upheld these clauses, though enforceability varies by jurisdiction and how overbroad the language is.

California provides the strongest statutory protection for employees here. Under California Labor Code Section 2870, employers cannot claim IP that is developed entirely on personal time, doesn't use company resources, and isn't related to the employer's business or anticipated research. Several other US states have similar protections. In the UK, there's no equivalent statute — making clear contractual carve-outs even more critical.

The Three Contamination Vectors That Can Destroy Your Claim

Even if your side project is legally clean on paper, courts and corporate IP investigators look beyond the contract. They examine what you actually did. Three specific vectors can compromise ownership of an otherwise personal project.

1. Hardware Contamination

This is the most common and most costly mistake. If you open your personal project once on a company-issued laptop — to push a commit, clone a repo, or even just check the dashboard — you've created a documented connection between the company device and your project.

Corporate IT systems log file access, network requests, and browser history. In a dispute, forensic analysis of a company laptop can surface timestamps, application logs, and metadata that your employer's legal team will use to argue the work occurred on company equipment. One accidental connection is enough to complicate things significantly.

The rule is simple: company laptop never touches your personal project. Not once.

2. Network Contamination

Routing personal project activity through a corporate VPN is a parallel risk that most developers underestimate. If you're working from home and connected to a work VPN while pushing code to your personal GitHub repo, network logs on the employer's side can show that traffic originating from the corporate network touched your project.

Similarly, using a company-licensed cloud environment — an enterprise AWS account for a quick test, a corporate JetBrains licence, a company Slack workspace to discuss your personal project — all create documentary evidence of company resource involvement.

3. Concept Contamination

This one is subtler. If your side project solves a problem similar to one your team is working on at your day job, or uses technology adjacent to your employer's product roadmap, your employer may argue the concept was derived from work done in your professional capacity. Courts have found in favour of employers where an employee's project showed clear "functional utility" to the employer, even when the product category was different.

The more your side project resembles anything your company touches — including adjacent verticals in a large conglomerate — the higher your exposure.

The Git Timestamp Trap

Software engineers often believe a GitHub commit history proves when they wrote their code. It doesn't — not in the way they think.

A commit timestamp records when you ran git commit. It doesn't record when you wrote the lines of code in the file, how long you spent writing them, or whether you wrote them during a meeting you were supposed to be in. A court doesn't accept a GitHub graph as proof of working hours. It looks at local file creation metadata, IDE session logs, corporate network activity records, and any communications (Slack messages, emails, calendar entries) that reference the project during work hours.

If you want a defensible record of when you built something, you need more than commits. You need a creation log: dated notes, local file timestamps from a personal device that was never connected to work networks, purchase receipts for your personal laptop and developer accounts, and ideally a timestamped external record like emails to a collaborator or a private journal entry describing the build.

The Pre-Existing Invention Problem

If you had a side project before you took your current job, you need to have listed it explicitly in the employment agreement before you signed — usually on an "Exhibit A" or "Schedule 1" page at the back of the contract.

Most employment contracts contain language like: "Except as disclosed on Exhibit A, Employee represents that there are no prior inventions." If you signed without listing your pre-existing project, you may have implicitly represented that it didn't exist — which creates a legal vulnerability if it grows into something valuable.

If you're currently employed and realise you missed this step, it's not necessarily too late. You can approach your employer about a retroactive carve-out. This is easier to negotiate than most people assume — but the conversation needs to be handled carefully.

How to Ask for a Carve-Out Without Triggering Red Flags

The fear of raising this topic with an employer is legitimate. Done wrong, it signals that you're distracted, planning to leave, or already competing. Done right, it's a professional, reasonable request.

Frame it around clarity and transparency rather than restriction. The conversation works better when positioned as:

"I want to make sure there's complete transparency about a personal project I've been working on in my own time. It's completely unrelated to our work here. I'd like to discuss adding a simple carve-out to my agreement so it's documented clearly on both sides."

Most employers — especially at companies that have standard processes for this — will accommodate a straightforward carve-out if the project is clearly unrelated to the business. The request itself doesn't have to be confrontational. What tends to trigger alarm is secrecy, not transparency.

If your employer refuses to grant a carve-out for a clearly unrelated project, that refusal is itself meaningful information about whether the clause would be enforceable and whether the employment relationship is tenable.

The IP Clean Room: How to Protect Yourself Going Forward

If you're building something independently while employed, the clean room approach is the only operationally sound method.

Set up your personal project on completely separate infrastructure: a personal laptop purchased independently, a personal internet connection not associated with your employer, personal accounts for every development tool (GitHub, Vercel, cloud providers, IDEs). Never use company SSO, company-licensed software accounts, or company network access for any part of the project — including research, ideation, or documentation.

Keep a timestamped creation log from day one. Record your working sessions in a private journal or dated document. Save receipts for your personal development tools. Store everything on a personal device that has never been connected to work systems.

If your contract contains broad "during the term of employment" language and you're in the UK, it's worth having an employment solicitor review it. The cost of a one-hour consultation is far less than the cost of finding out your contract was enforceable after your product takes off.

Practical Takeaway

Your employer's ability to claim your side project has almost nothing to do with what time you wrote the code and almost everything to do with what your contract says, what device you used, and what network you were on. The statutory defaults protect you far less than most guides suggest — because most contracts override them. If you're building something independently, the three things that matter most are: get a carve-out in writing before or as soon as possible, never touch your personal project on a company device or network, and keep a proper creation record from day one. These three steps turn a legally grey situation into a defensible one.

This article is for general informational purposes only and does not constitute legal advice. Employment IP disputes involve jurisdiction-specific law and contract-specific analysis. Consult a qualified employment solicitor or IP attorney for advice on your specific situation.

FAQ

Does my employer own what I create outside of work hours?
Not automatically under default law — but your employment contract may say otherwise. Clauses using the phrase "during the term of employment" or "whether or not during business hours" can assign your personal-time creations to your employer if you signed them. The clock doesn't determine ownership; the contract does.

What happens if I use a work laptop for a personal project?
Using a company device creates a documented legal connection between your employer and your project. Corporate devices log file access, network requests, and application usage. In a dispute, that data can be used to argue the work occurred on company equipment — regardless of whether it was during work hours.

What is an IP carve-out and how do I get one?
An IP carve-out is a written amendment to your employment contract that explicitly excludes a specific personal project from your employer's IP assignment clause. You request it by approaching your employer transparently, framing the conversation around clarity and documentation rather than restriction. Most reasonable employers will agree for projects clearly unrelated to the business.

What is "Exhibit A" in an employment contract?
Exhibit A (or Schedule 1 in UK contracts) is a section at the back of an employment agreement where you list any pre-existing inventions or projects you want excluded from the IP assignment clause. Signing without completing this exhibit — or leaving it blank — may imply you represented that you had no prior inventions.

Can an overbroad IP assignment clause be challenged in court?
Yes, in some jurisdictions. California has a statute (Labor Code Section 2870) that voids clauses attempting to claim IP created entirely on personal time without company resources. Some other US states have similar protections. In the UK, there's no equivalent statute — courts may consider whether a clause is unreasonably broad, but this is an expensive argument to run. Prevention through a written carve-out is far more effective than litigation.

What is "IP contamination" and how does it happen?
IP contamination refers to any connection between your personal project and your employer's resources — devices, networks, accounts, or licensed software. Even a single commit pushed from a company laptop, or a test run through a corporate VPN, creates a documented point of contact that an employer's legal team can use to assert a claim. Keeping personal projects on entirely separate infrastructure prevents this.