Google Just Fired the Engineer Who Built Its Viral Workspace CLI. Can Your Employer Own Your YC F26 Startup?

Two months ago, Justin Poehnelt built an open-source Google Workspace CLI. It hit #1 on Hacker News, pulled thousands of GitHub stars, and racked up many thousands of real users in a couple of days. On June 23, 2026, he posted the part nobody expected: Google had fired him for it. To sharpen the irony, Google Cloud Next announced an official Workspace CLI two days before his termination, and his thread says legal had been grilling him about why Google's logo and brand colors were on the repo.

If you're sketching a YC F26 application during nights and weekends at a day job, this story should stop you cold. The single most common question we hear from applicants getting alumni feedback through YC Roaster isn't about traction or TAM. It's some version of: can my employer take this from me? Here's the honest answer.

Can your employer legally own a startup you build on the side?

Sometimes, yes. Almost every tech employee in the US has signed a Proprietary Information and Inventions Assignment agreement (a "PIIA," usually buried in your offer letter). The default version assigns to your employer anything you invent that relates to their business, that you build on company time, or that you build using company equipment or confidential information.

The critical nuance, and the thing most founders get wrong, is that these agreements are not unlimited. In California, Labor Code Section 2870 voids any clause that tries to claim an invention you developed entirely on your own time, without company equipment, that does not relate to your employer's business or anticipated R&D. Washington, Delaware, Illinois, and a dozen other states have near-identical carve-outs. So a Salesforce engineer building a consumer fitness app on a personal laptop at home is usually fine. A Salesforce engineer building a CRM-adjacent AI agent is in genuine danger.

Poehnelt's situation is the cautionary version of the second case. A Google employee built a tool wrapping Google's own APIs, branded with Google's own assets, that directly overlapped with a product Google was about to ship. That's the maximum-overlap, maximum-risk quadrant. Whatever you think of the firing, the legal exposure was real.

Does YC care whether you've quit your job?

YC funds people who are still employed all the time, and the application explicitly asks how much time each founder spends on the project. But "still employed" and "about to be sued by your employer" are different planets. YC's standard deal documents and the partners' due diligence will surface IP ownership fast, because an unresolved invention-assignment claim is the kind of thing that scares off the next round's investors.

The practical bar is this: by the time you sit in the 10-minute interview, you want to be able to say, truthfully, that you own your IP free and clear. Founders who were technical employees at a directly competitive company are the ones who get the pointed follow-up. If that's you, the partners will want to hear that you built the startup cleanly, on your own time and gear, in a space your employer doesn't operate in, or that you've already had the conversation and gotten a written release.

How do you build a YC startup while employed without a Poehnelt outcome?

A few concrete moves that separate the founders who keep their IP from the ones who lose it:

• Read your actual PIIA, not the memory of it. Find the carve-out section. Many agreements let you list pre-existing or excluded inventions on a schedule; if yours does, list your project before you write a line of code.
• Physically separate the work. Personal laptop, personal accounts, personal GitHub, and time that is provably outside work hours. Poehnelt's repo carried Google branding; yours should carry nothing that ties it to your employer.
• Stay out of your employer's lane until you've left. The closer your wedge is to your day job's roadmap, the weaker your Section 2870 protection. If your startup competes directly, the safe sequence is: quit first, then build the competitive version.
• Get the release in writing if it's close. A two-line email from your manager or legal confirming the company has no claim is worth more than any verbal reassurance. Founders routinely underestimate how cheap this is to get before a tool goes viral and how impossible it is after.

What's the actual lesson for F26 applicants?

The seductive misread of this story is "big companies are scared of agents, so there's a wedge here." That's true, and Poehnelt himself attributes the firing to Workspace's fear of being disrupted by agents. But the wedge isn't the lesson for your application. The lesson is that the thing that made his project valuable, deep integration with his employer's own surface, is exactly what made it un-spinout-able. The best version of his project for a YC founder would have been built one inch to the side: an agent-native CLI for a platform he didn't work on, where he owned every line.

That's the reframe to bring to F26. If your startup only works because of access, code, or relationships you have through your employer, you don't have a company yet; you have a conflict of interest. If it works because of an insight you can legally carry out the door, you have a founding story YC will love, the kind where domain expertise from a job becomes a startup the job could never have built.

If you're in this exact bind, deciding whether your nights-and-weekends project is clean enough to build on or close enough to your employer's business to be radioactive, it's worth pressure-testing with someone who has been through a YC diligence process. Getting a YC alumni founder to read your one-liner and your situation on YC Roaster before you submit is a cheap way to catch the IP landmine that a partner would otherwise find for you in the interview.

Poehnelt landed fine; he's got 1.1 million views, a renewed reputation, and presumably his pick of next moves. But he also lost the project. For F26, build the version you get to keep.