If you introduce a bug bounty too early, you will be paying out for vulnerabilities that could be caught or prevented in a much more cost effective manner (vulnerability assessments, penetration tests, developer training, appropriate monitoring).

Daniel Miessler has a good breakdown of when to consider various types of security testing: https://danielmiessler.com/blog/when-vulnerability-assessmen...

Sqreen also have a handy basic security checklist: http://cto-security-checklist.sqreen.io Specific to bug bounties they say "You need security aware people inside your development teams to evaluate any reports you receive."

Alex Stamos gave a great talk a while back at https://www.youtube.com/watch?v=2OTRU--HtLM while he was at yahoo. Among the things he covered were the risks of bug bounties.

[Edited to add following]

Another article http://searchsecurity.techtarget.com/opinion/Is-the- bug-bounty-program-concept-flawed "There can be a lot of noise in these systems, and the quality isn’t always there, nor are the findings always significant."

And from the same article Google says "Approximately 90% of the submissions we receive through our vulnerability reporting form are ultimately deemed to have little or no practical significance to product security,"

The issue I've read about (I'm not a security practitioner, more like a hobbyist) is that the sheer mass of bogus bounty submissions take valuable time to evaluate. If you start up a bug bounty program, you're essentially signing up to read hordes of submissions that you'll be obligated to check out, the overwhelming majority of which pan out to be nothing. And many (most?) of those, will contain petulant and arrogant demands that the bounty be paid even though the "finding" presented is no actual vulnerability at all.

I'd rather see if someone else wants to take a swing at that softball lob first.