Is it a bad idea if I build the MVP of my startup on my company’s pc?

Friday evening, everyone has left, and that shiny M1 on your desk is begging for overtime. Tempting, I know — the build times are twice as fast as on your five-year-old personal laptop. Short answer: don’t touch it for your side project.

Long answer: Founders have been wrestling with this since before GitHub was a thing. You spot an opportunity, you want to move fast, and buying a separate machine feels like needless friction. Been there. When we were hacking together the first prototype of a news-scraping API a few years back, my co-founder and I ended up grabbing two used ThinkPads off eBay (less than the monthly cost of a decent coffee habit) and working out of his kitchen after hours. The gear was slower, sure, but the IP line stayed crystal clear. In hindsight, that clarity saved a lot of paperwork later when we were pitching investors, though not all situations resolve so neatly, and sometimes challenges persist despite precautions.

Most employment contracts I’ve seen — Swiss, German, U.S., doesn’t matter — have a “work-for-hire” clause lurking somewhere. Anything produced on company time or equipment belongs to the company. Simple, brutal. (I’m not a lawyer, just a CTO who has had to sign more of these than I’d like.)

There are exceptions. A few forward-thinking enterprises explicitly carve out nights-and-weekends projects or even encourage engineers to open-source internal tools. If you’re lucky enough to have that wording, congrats — but read the fine print twice. I’ve misread those clauses before and needed legal to untangle things later.

Consequences scale with your success. A half-finished hobby app? Probably no one cares. A Series A term sheet? Suddenly procurement logs and commit timestamps become evidence. Good luck explaining to investors why your cap table might include your former employer. (I’ve seen a deal stall for six weeks over exactly this.)

Ethically, borrowing company hardware feels like a harmless shortcut — until it isn’t. Any shortcut that blurs ownership tends to bite back. The same skepticism I apply to “promised” low-code miracles applies here: if it looks too easy, I assume hidden costs.

So what are the real options?

• Buy or borrow a machine. Doesn’t have to be fancy; reliability beats speed at this stage.
• Cloud IDEs like Gitpod or Codespaces. Handy, yes, but keep local backups — ToS can change overnight and whole services disappear (I still miss Cloud9’s old free tier).
• Rent hardware month-to-month. A couple of bootstrapped teams I know swear by this — when the project dies, so do the bills.

I could be wrong, but investing a few hundred up front is cheaper than legal clean-up later. If the cash isn’t there, hunt for startup grants or accelerators — many hand out cloud credits and hardware stipends precisely to avoid this mess.

If you’re still unsure, spend an hour with an IP lawyer. Yes, it’s expensive. So is undoing a bad assumption once you have traction.

In the end, the extra friction of separating work and side-work is annoying, but it buys you ownership certainty. And ownership certainty is the one asset a pre-revenue startup actually has.