← Back to Posts

Bugbop - First Year in Review

7 min read Founder Post

It's been a year since Bugbop was launched. TL;DR: it's been an exciting year of building and learning, especially about where the market isn't.

Metrics

Here is a snapshot of activity from the first year of Bugbop:

5
Programs Run
39
Active Hunters
221
Bugs Reported
$11,810
Bounties Paid
Status Critical High Medium Low
Fixed 3 13 31 15
Active (New/Open/Needs Info) 3 9 23 33
Won't Fix - 4 4 31
Duplicate - 2 2 4
Not Applicable - 3 5 36

I'm most proud of the Critical bug reports. When a Critical gets found, there's always that "Thank goodness we caught it!" moment.

I was surprised by the high number of "Not Applicable" reports so I'm planning to address that early in 2026. The AI triage spots these scope issues well but it needs to be before the bug is raised to save real time. Active bugs also seem high but this number reflects the reality that some security issues simply take time to prioritise and fix.

Building It

Prior to this year, I'd been considering building a new platform for a long time. I had a handful of conversations with people in my network that went well - "Yeah, I'd use something like that!". All very promising at the time. I've built successful businesses before so I started building! 🚀

I had been working on the same app I started (Gleam.io) for over a decade so starting a green fields app was a breath of fresh air. Using Rails 8 by-the-book (Stimulus, Hotwire, etc) has been a delight. Using AI code assistance & interactive documentation has been a huge help. I still don't trust the AI to write good quality code so I'm treating it like a hyper-enthusiastic junior developer and reviewing everything it does.

The app isn't doing anything especially novel technically. It's Finite State Machines for the main models (program, bug report) with user roles, payments, moderation, etc. Plus a sprinkling of AI features where it made sense (AI bug triage, summaries, etc). I'm a builder by nature, so the building has been my favourite part.

Validation

Early in 2025, I started doing discovery chats via my network. I've got a broad network of entrepreneurs and tech people so this part was easy. There was plenty of enthusiasm and people were happy to give advice and feedback. But very few were willing to commit to a bug bounty program.

A few months into 2025, I read a book called "The Mom Test" about truly validating your idea and asking the right questions. It's a great read if you're thinking about building something. In hindsight, I came to this book later than was ideal, though I'm not sure I would have built Bugbop at all if I had.

Throughout the year, I reached out to about 2,000 people outside of my network (mainly via LinkedIn but also in-person meetups/conferences) which led to about 300 conversations focussed on validating the idea, objections, and potential pivots.

The Main Problem

The main issue for Bugbop is that companies simply don't have to run bug bounty. Rob Snyder wrote an excellent piece on the PULL Framework that explains why this is so important. The "U" in pull stands for unavoidable and bug bounty is avoidable. Even for the largest and most risk adverse companies (FAANG, cryptocurrency), they can still get away without running it. Once a company reaches the size where it should be running bug bounty, they're typically past the stage where the price of an enterprise platform matters.

For the market I originally targeted (small SaaS), they can simply do nothing or run disclosure via their security@ email and that'll be fine. It's not the best approach (imho) but it's enough to keep bug bounty in the "maybe one day (a.k.a. never)" pile.

Solving the Two-sided Marketplace

Building a two-sided marketplace is notoriously hard. Rob Walling has created excellent content on why this is so. Fortunately, one side of Bugbop's marketplace, Bug Hunters, has been relatively easy to solve.

The reality is that many of these bug hunters are happy to be on all platforms. They join whatever programs they can find and add them to their list. The platform only starts to matter to when they're getting in to exclusive programs or getting stiffed on a bounty.

In the early days, I invited a few bug hunters I had worked with previously. There's been a steady stream of more bug hunters signing up for the platform since.

Pivot 1 - Pricing

Originally, the pricing was a placeholder - $49/month SaaS-style pricing. This proved deeply unpopular. You get a lot of amazing software for $49/month these days and people baulked at this price.

The second pricing was bounties only. $0 ongoing fees and they only have to pay for bounties (+ a %10 fee). This was seen as too cheap and showed a lack of commitment (by both bounty hunters and program runners).

The current pricing is an initial payment of $575 to list the program publicly (they can still run private programs for free) that goes in to their bounty "wallet". This shows that the program is committed to paying some bounties and reduces spam (which was a minor problem). The investment covers $500 in bounties and $75 in fees (@15%) which is enough to pay for a few good bugs and get them to that "Ah-ha!" moment.

Bugbop pricing page showing the $575 one-time payment which includes $500 in bounty credits
The new pricing model requires an upfront deposit which acts as a 'wallet' for bounties.

The downside of this pricing is that there's considerable friction in paying so much up front (even with the money back guarantee) but hopefully this is mitigated as the platform becomes more trusted.

Pivot 2 - Managed Service Providers/Pentest Companies

One feature of Bugbop's pricing is that it doesn't include bug triage (which typically costs $10ks/year). Based on several conversations I had, it was suggested there was an opportunity to allow program runners to use 3rd parties (e.g. their MSP, pentesters) to do that function for them.

The MSPs/pentest companies were happy to do this - I could refer them customers who wanted 3rd party triage and they could offer another service. It could also increase stickiness of their offering as the relationship is kept warm by triaging bugs that are reported.

This turned out to be a red herring. The programs I had running already were happy to self-manage this. The 3rd parties were willing to offer this service but their customer needed to want to run bug bounty first. The Bugbop workflow still allows this model but its looks to be a tiny market at best.

Pivot 3 - Vibecoded Apps

2025 was the year of vibecoded apps. It's widely understood that security of these apps isn't great. I've been using AI-assisted code extensively this year and I see the insecure code it writes. Tea was a particularly high profile case. But even now they're not running any disclosure programs.

Surprisingly, it was quite hard to find people in the vibecoding space willing to talk about security given its prominence on social media. Of the few I spoke to, security simply wasn't a priority. There's a lot more they can do for security before they get to running bug bounty (e.g. professional pentests, audits, automated upgrades, CI/CD checks, etc). Bug bounty gets deferred to the later phase when the app will get "professionally rewritten" later (e.g. enough revenue, Product-Market Fit, funding).

There's also the issue that many of these companies struggle to run a bug bounty program. If your entire team is one non-technical founder, they're just going to ask AI to solve the issue anyway. I've done AI security audits and tried to get it to write fixes but it misses the mark often (e.g. in-app fixes that should be done in Cloudflare) and breaks things.

Pivot 4 - Cheaper Alternative or First-Time Bug Bounty?

I originally positioned Bugbop as a cheaper alternative to the established platforms. Over time, it's become clear that a better fit is being the platform for companies running a bug bounty program for the first time.

Most of the conversations I had weren't about price, they were about uncertainty. These people weren't running anything (or just a simple disclosure program) and were still figuring out whether a bug bounty made sense at all. As first timers, they wanted to know what it looks like in practice. Every onboarding call I've done has always involved a walkthrough of how our program is running and what to expect (and it's not that scary after all 😅). The low pricing allows them to start small plus they don't have to commit to a huge program as they can start/stop the program at any time/budget.

What Now?

Bugbop does what it's meant to do: companies can run programs to secure their apps, and bug hunters get paid for finding real security issues. The ongoing expenses are low, and I love running it, so I'm going to keep it going as a focused product for small to mid-sized teams running their first bug bounty program.

It's not trying to replace the enterprise platforms I once imagined competing with. Instead, Bugbop is built for teams that care deeply about security and want a simple, low-risk way to get started with bug bounty.

Official Launch 🚀

Now that I've got clarity on what Bugbop is, I'm officially launching it on Product Hunt. If you've found this write-up interesting, I'd really appreciate you joining the conversation there (and an upvote wouldn't hurt 🙏).

Not sure about bug bounty?

I've spent the last year talking to teams about whether bug bounty makes sense. If you want a friendly, no-sales conversation, book some time and we'll talk it through.

Follow Our Content

Get the latest security insights and company updates