Duplicate. Duplicate. Informative.

Hello, I am Nitin.

This is the post about the part of bug bounty that nobody puts in a thread.

There is an enormous amount of content about the moment somebody gets paid. There is almost nothing about the eleven months before it, which is where most people quit, and which is the only period that actually determines whether you make it.

So here is that period, described accurately.

What it actually looks like

You find something. You are genuinely excited, because you found it yourself, by noticing something and pulling on it.

You write it up carefully. You submit it. You refresh the page more often than you would admit.

Duplicate.

Somebody submitted the same thing. Possibly four hours earlier. Possibly eight months earlier and it is still open. You get no money and, depending on the platform, you may get nothing that helps your standing either.

You find something else. Duplicate.

You find something else. Informative. It is real, it is confirmed, it does not meet the bar for a reward because you did not establish impact, which is the subject of an earlier post in this series and which took me an embarrassingly long time to learn.

You find something else. Triaged. Then it sits. Weeks. You wait, you check, and the waiting is genuinely harder than the rejections because hope has a cost that rejection does not.

That is the loop. For most people it runs for months before the first meaningful payout.

Why duplicates dominate, structurally

This is not bad luck and understanding the mechanism makes it much easier to bear.

Payouts are extraordinarily concentrated. In a recent twelve-month period, the top 100 programmes accounted for 51 million dollars out of 81 million paid across roughly 1,950 programmes, and the top ten alone accounted for 21.6 million. The programmes that pay well are the programmes everybody hunts.

On top of that, around 70 percent of surveyed researchers now use AI tooling in their workflow, and autonomous agents have begun submitting valid reports of their own. The surface that a script can cover is being covered, continuously, by a large number of people and an increasing number of machines.

So if your methodology is enumerate the target, run the scanner, submit the finding, you are competing on speed against automation that does not sleep. Duplicates are not a sign you are bad. They are a sign you are hunting where everyone else is hunting, with the tools everyone else has.

What actually changes the outcome

Three things changed my rate, and none of them were a new tool.

Depth. Pick one target and understand it properly. Read its documentation. Understand its business logic, its user roles, what actions cost money, what actions cross a tenant boundary. Business logic flaws are almost never duplicated, because they cannot be scanned for. They require somebody to understand what the application is supposed to mean, and that is expensive, which is exactly why it is unoccupied.

Newness. The most valuable window is right after something changes. A newly launched feature, a new API version, a recently acquired company folded into scope, a fresh mobile release. That surface has not been picked over because it did not exist last week. Watching for change is a strategy in itself.

Impact. Half the findings I initially discarded as boring were reportable, and half the findings I reported were undersold. Learning to chain a low-severity issue into a demonstrated consequence converted more of my existing work than any new technique added.

The emotional mechanics, honestly

I want to say something about this because it is the actual reason people quit and it is never addressed.

Bug bounty has an unusually cruel reward structure. Effort is continuous. Reward is rare, unpredictable, and arrives on somebody else's schedule. That is a variable-ratio schedule, and it is the same structure that makes gambling compelling and exhausting at once. It will keep you engaged past the point where it is good for you and it will make a duplicate feel like a personal verdict.

Three things that helped me.

Measure inputs, not outcomes. Hours of focused testing, targets understood, reports written. Those are within your control. Bounties are not.

Keep a findings journal, including the ones that paid nothing. Every duplicate is proof you found a real bug. That is skill evidence and it is invisible on a platform profile.

Do not do this as your only income while you are learning. This is practical advice, not motivational. The financial pressure will push you towards fast, shallow, high-duplicate hunting, which is precisely the strategy that does not work. I did client work and training alongside, and that is what let me hunt deep instead of desperate.

The thing I would tell myself

Duplicate means you found a real vulnerability in a real system. Somebody was just faster.

Informative means you found a real vulnerability and did not make the case. That is a writing problem, and writing problems are the most fixable problems there are.

Neither of those is the market telling you to stop. Both are telling you exactly what to change, which is more than most fields give you.

The people who make it are not the ones who found something brilliant early. They are the ones who were still doing it in month eleven.

Conclusion — steal this checklist

• Expect duplicates to dominate early. Payouts are concentrated in the programmes everyone hunts, and automation covers the shallow surface continuously.
• Stop competing on speed. You cannot outrun tooling that runs constantly.
• Go deep on one target. Business logic flaws are rarely duplicated because they cannot be scanned for.
• Hunt change. New features, new API versions, new acquisitions and fresh releases are the least picked-over surface there is.
• Re-examine your discarded findings for impact. Chaining converts boring into reportable more often than new techniques do.
• Measure inputs you control: hours, targets understood, reports written. Not bounties.
• Keep a journal of every finding including duplicates. It is the only honest record of your skill growth.
• Do not make this your sole income while learning. Financial pressure forces the shallow strategy that fails.
• Read Informative as a writing problem, not a verdict.