TL; DR: There is no perfect solution. Self-funding is mine.
This question comes up all the time. I have been doing this for a while and this is the most difficult part of being a tech entrepreneur. I have yet to find a single, go-to, comprehensive solution for this problem. Every option seems to come with its own unique set of negative unintended consequences. So it comes down to choosing which set of negative unintended consequences you want to live with.
However, since you are a developer, you have one key option that is not available to non-developers. This is the option I have opted for several times myself (as I am a developer too). It is this:
Go it alone. Develop your product without any outside help and self-fund its development.
The problem with VCs and NDAs.
The scenario you describe in your OP is definitely a possibility. Many VCs won't sign an NDA. At least not until they agree to a deal. And by "many," I mean most if not all. If you look around the internet you will find much written about how approaching VCs with NDAs before pitching them makes the entrepreneur seem naive, amateurish, un-savvy, etc. And, AFAIK, VCs have many more pitches than they can read or hear. So they can just move on to the next pitch if you insist on an NDA.
The problem with patents. The patent field is so technical and complex you really need a lawyer to do it. And lawyers are expensive. And if you are like me, as a developer, you probably have more product ideas than you have time to build them all yourself. So, obtaining a patent on each idea when you get it is... expensive. Probably prohibitively so. Also, I heard somewhere they are no longer issuing "process patents" which applies to most software and apps. Although that might be a false rumor. Don't go by what I say here; do your own research. Also, you might already know, the moment you write your code, you receive copyright protection. Your remedy for all IP protection is to sue. Again, expensive.
The problem with partners this includes co-founders as well as money parters like VCs, seed funders, angels etc. is the potential for disputes about who owns what. Especially if you already have your own code base. I've had a prospective co-founder demand the rights to all the code I have ever written. Obviously preposterous. But in my experience, non-technical co-founders have a tendency to vastly overvalue their contribution and vastly undervalue yours. I think this is because only a developer can know (because you've done it) how difficult it is to develop something, write the code and make it work. Non-developers tend to estimate about 1% of the actual time, effort and knowledge it takes. There's no way you will make up that gap when you start negotiating ownership with a (newbie) non-tech co-founder. Also, if you are smart, you will want to reuse a lot of your code base on your next project. And many more after that. The potential for disputes about this is increased dramatically if you add partners. Even one. Also, at many key points you might have to pivot on your concept or some important element of your strategy or implementation. Again, as soon as you add that second person, you have to get people to agree. That takes time, effort and there is a real cost in potential for sub-optimization or outright company-ending disagreements. Aside: Did you know the number one reason for startups failure is disputes among the management team?
Startups only do two things: product development and sales. Before the product is developed there is nothing to sell. So if your prospective partners aren't writing code, what value do they really have anyway?
The problem with self-funding. It takes a looooooong time. To build anything substantial. It's hard work and long hours with no immediate compensation. However, I have found it to be worth it. Once you are revenue positive, it will be a lot easier to bring people on board with terms that are more realistic.
The most useful ideas I've found for achieving positive revenue are:
You need to be full-stack. This includes front-end. I started writing my first app with the back-end first but eventually came to grips with the fact that the user is going to eventually have to interact with the product. Fortunately, last year I stumbled across Polymer (a Google open source project). And an excellent solution for taking advantage of the web-components spec and allowing for front end development to reuse these "web components" and focus on only writing what's new for each app. Less than one year in production. Otherwise, a good front-end solution would be even more challenging.
Slow and steady wins the race. Accomplish (at least) one thing per day. When you develop solo and self-fund you enter a marathon not a sprint. Each day of that marathon you need to stay motivated and on track. A technique that has been effective for me is to set a daily goal of accomplishing one major, complex task (or set of tasks) each day with a clear product or deliverable. And I try not to sleep until I succeed. Sleep has become my de facto self-reward mechanism.
You need to work backwards in your design. Hopefully, you have started with a solid core of domain knowledge about the environment your product will be used. How things are currently done in the industry. And what your customers, clients or users will really need. So my trick has been to focus on the user. Understanding them and their needs. Then incorporating all that into the product design and strategy.
Build it first. Customer feedback is invaluable. But they need to see something. Build a prototype. Then start reaching out to customers. If you point them to a nice looking, working app (without all the bells and whistles) you gain instant credibility. They will give you useful feedback that you then recycle back into the product design. Repeat that process until you have something people are willing to pay for.
Trim out all the fat. Meaning you probably won't need all the features you currently imagine in your product. Identify the essential few. There is a concept called minimum viable product. Look it up. Understand what that means. Focus on your MVP then release something. Add the bells and whistles later in future releases. Product upgrades. Or premium pay services.