Oh, please. It's standard industry practice for companies to claim ownership of everything a software engineer comes up with, even "on their own time". The problem is it's extremely difficult to say, figure out when someone might have invented some super clever idea which can be pantented "on their own time". This was true when I worked for MIT, VA Linux, IBM, and Google. At VA Linux it was the VC's which insisted on…
It's absurd for any company to say they're going to attract passionate programmers, and then expect them to just roll over and give up projects that were started before they even joined at the company. If you're Google, you can get away with this because you just throw so much money at people that they're willing to temporarily put their life on hold for 3-4 years. But for any other company, people who are genuinely…
Most cases where an employer claims ownership of something an engineer did on their own time, it's because the engineer decided to create a competing product and used information or other ip they only had access to as an employee. The guy trying to sell his competing product doesn't want to acknowledge that they've violated a non-compete or NDA they signed, so they publicly claim their employer is just being a bunch of greedy bastards. When you dig into known cases of employers claiming ownership of an employees outside work there are cases where they worked on it before they joined, but those are outliers, and having initial work from before joining doesn't mean that later work hasn't infringed on the employers existing IP.
This topic is often complicated, but the realistic answer is that you should always tell your employer that you've started working on something and have it acknowledged as yours way before any valuable IP is created. Not doing so isn't just irresponsible, it's a known business pattern that results in failure. You should ideally tell them before you've even answered the question of how you intend to do it. Nobody is going to steal a vague idea, so this just eliminates the possible argument later. A lack of ability to trust is a strong indicator of eventual failure of the project anyway, so there simply isn't a reason to avoid doing it.