[shawnreilly]

I've been in a similar scenario. I bootstrapped my first Startup. It failed, and I lost a lot of money. We developed (in Stealth) an amazing product in the "Ambient Discovery" space. We didn't call it that, but that's the buzzword that everyone started using. Anyway, turns out a few other Startups were developing in the same space (in Stealth). They executed faster than we did, and they had better connections. We were too slow, and other Teams launched / secured funding before we could. Ironically, it turns out that the Market never truly embraced the idea, and it kind of flopped. The timing was off. The idea itself was ahead of its time and the Market was not ready for any of these Products. Some Teams got funding, but I never heard about them again. One Startup made an exit (good for them!). Everyone was ahead of the curve. Everyone failed. Doh!

I don't really have any input about the plausibility of your hypothetical scenario (too many variables), but I do have some advice; Do not assume that you know what your customer wants. This is a harsh concept. Everyone loves their own ideas (myself included). But falling in love with your idea can become detrimental to product development. When it comes to the product, the Customer is King, not the Idea. If you can embrace this, you will become more effective at building your product. This lesson could have saved me lots of money on my first Startup. Instead of assuming things, validate with the customers (or potential customers). Do not leave it up to chance. Why am I saying this? You've laid out what seems to be a pretty "hands-off" approach to building the Product. I would recommend defining a relationship with your Developer that allows you to continually integrate customer feedback into the development process. This will likely result in a product that is more aligned with what the customers actually want, which should increase your likelihood for success.

[vik1211]

Thank you. 100 pct agree. Hands-off was meant to convey respect for Hacker's process and craft of building out a MVP. As far as customer acquisition, feedback, service -- 100 pct hands-on. For some reason (most likely bad writing) my original post didn't convey that.

The idea would solve a personal pain point. And the MVP would test whether that pain point was felt by others. If not, failing fast is okay.

Relationship with Hacker is key to long term success. If Non-technical isn't plugged into the Hacker community, compensating them is a way to demonstrate seriousness. Skin in the game, so to speak.

Also, I'm speaking in broad terms -- Hacker and Non-technical -- for universal discussion. This scenario could apply to me at some point but I also deal with a lot of clients and associates that actively talk about similar scenarios at barbeques, dinner parties and conference rooms.

I don't have a confident road map to advise them on such a course and I'm genuinely interested in what this community thinks would be the best may to make this situation work -- for the sole purpose of launching a MVP -> shipping -> testing -> refining -> scaling.