I thought i'd chip in (having seen my umpteenth dupe
The reality is the real advice for avoiding duplicates comes with bugcrowd understanding that they are provided with the url, the parameter, and possibly other info that might be useful to create Dupe indicators
the last thing i want to see having received the bad news of a dupe is tips on how not to find dupes that are as quite generic (no offence casey! ) all bugs are bugs easy and hard ones.
if bugcrowd used the information it has and doesn't has, it could create small queries on submission that looked for the parameter , the url or both and give a confidence score regarding dupe likelyhood
that would be 10000% more useful than being told dont look for easy to find issues or what not
less duplicates is more a bugcrowd problem, if you look at every webapp methodology it will tell you coverage, not skip the easy places
especially if you've been invited to private gigs that have been active for 200 days ... where to start ? whats the point ? the advice is bad advice ... i'm only writing this because I dont like being told be the first when the program is in it's Nth week/month, who does this advice apply too
Dupes problem should be revisited by Bugcrowd Engineers as a opportunity to minimise time for all parties