Side Project While Employed

Does my employer own the side project I build after hours?

It depends on three things: what you signed, which state you work in, and whose resources the project touched. Nearly every senior tech offer includes an invention-assignment clause that claims IP you create using company equipment, on company time, or inside the company's line of business. Read that clause before you write the first commit — not after you have users and something worth fighting over.

Several states narrow how far that clause can reach. California's Labor Code 2870 is the well-known example, and Washington and a handful of others have similar carve-outs for work done entirely on your own time, with your own equipment, and unrelated to the employer's business. The protection is real, but the word 'unrelated' carries all the weight. A weekend tool that slowly drifts toward your employer's product is exactly where a clean ownership story quietly falls apart.

In practice, keeping the project yours means never letting it borrow the specific things that trip an assignment claim:

How much time does a side project need while you're working full-time?

Plan for 5 to 10 focused hours a week and shape the project to fit that budget, rather than picking an ambitious scope and hoping the hours appear. Your employer has the first claim on your sharpest cognitive hours by design; a project that only ever runs on the depleted 30 minutes before standup will stall out. The scarce input isn't calendar time — it's the mental energy left to make a non-trivial decision at 9pm. Protect your day-job performance first, because a side project that quietly tanks your review has burned more career leverage than it built.

Your day job will also interrupt this project constantly — a late release, an on-call rotation, a reorg — so the real fix is making the work resumable. Break the project into units small enough to finish in one sitting, and end every session by writing the literal next step, down to the file or command. Rebuilding lost context after a two-week gap is the tax that kills most employed builders, far more often than a shortage of raw hours does.

• →Defend one uninterrupted 3-4 hour block on the weekend — that's where real progress lands, not the scattered weekday scraps
• →Leave a written 'next action' at the end of every session so you resume in five minutes instead of re-deriving where you were
• →Do the thinking-heavy work — architecture, positioning, pricing — while fresh; save mechanical grunt work for tired evenings
• →Cap it deliberately: a project that creeps to 25 hours a week will surface in your day-job reviews as divided attention
• →Treat a brutal week at work as a legitimate reason to pause the project, not to push through and show up wrecked on Monday

Do I have to tell my manager about my side project?

There's no universal rule, but for a genuinely separate project the default is: you don't have to volunteer it, and you're usually better off not making it a topic at work. Disclose when your agreement explicitly requires written approval for outside work, when the project could touch your employer's customers or market, or when it has grown large enough that later discovery would read as concealment. If you do disclose, get the acknowledgment in writing — a friendly verbal 'sure, no problem' from a manager who later leaves protects you exactly zero.

Keep the two worlds socially separate as well. Don't demo it at your desk, don't pitch coworkers to join, and don't let side-project stress bleed into how you show up in standups. Every coworker who knows is one more person who could mention it during a review cycle you don't control.

How do I pick a project that won't create a conflict of interest?

Choose a problem your employer would never plausibly ship. The safest side projects sit in a different domain, serve different customers, and solve a need that isn't anywhere on your company's roadmap. Adjacency feels efficient — you already know the space, the users, the failure modes — but adjacency is precisely what dissolves the 'unrelated to the business' protection and hands anyone an easy conflict-of-interest argument. If your project could be mistaken for a feature your employer might add next year, that's your signal to pick a different project.

Then read your agreement for non-compete and non-solicitation terms, which survive independently of who owns the IP. Building in your employer's exact market can breach a non-compete even if you wrote every line at home on your own laptop; recruiting colleagues as cofounders can breach non-solicitation even if the product is unrelated. Neither of those has anything to do with how carefully you separated your machines — they're a separate class of trap, and clean IP hygiene won't save you from them.