Why I shut down my bug bounty program after three months

I launched Killswitch at the start of 2026 with a bug bounty program. A zero-knowledge service is supposed to be trustworthy, and a public bounty page felt like part of the price of admission. Three months later I shut it down — torched the page, scrubbed every mention from anything Google can index, and rewrote our policy so active security testing is restricted to paying customers.

This post is what I would tell another solo founder before they make the same call I did.

The structural shift

The framing that reframed this for me came from Michael Lubas, CEO of Paraxial.io, who I had back on the Elixir Mentor Podcast a few weeks before publishing this. Michael does penetration testing for a living — Paraxial was one of the firms hired to pentest the Hex package manager — and partway through the episode he started talking about the state of bug bounty programs in 2026.

His one-liner on the show: "defensive cyber security people, bug bounty programs are shutting down. People are saying we just don't have the resources to handle this volume." The Internet Bug Bounty program shut down. Node.js shut down theirs. The list keeps getting longer.

The numbers he shared are the part worth keeping in your head. The Erlang Ecosystem Foundation issued nine CVEs total in 2025. In 2026, they're on track for well over a hundred, possibly over two hundred. Firefox went from an average of roughly twenty valid bug reports a month in 2025 to over four hundred in a single month — April 2026. As Michael put it: those bugs already existed in the source code. The bottleneck was finding them, and AI just blew the bottleneck out of the water.

If you're a solo founder reading this, that's the part that matters. The firehose of reports landing in your inbox is not a comment on your product. It's a structural shift in the cost of vulnerability discovery, and your bounty page is just downstream of it. The mental model of "more eyes = better security" assumed a fixed supply of eyes. That assumption is gone.

The full conversation — including why Michael thinks AI is also good news for defenders, what it means for Elixir specifically, and his strong recommendation that maintainers run zizmor against their GitHub Actions — is on Elixir Mentor Podcast episode 83.

What actually landed in my inbox

Within a few weeks of launch, a meaningful chunk of my inbound was beg-bounty hunters running checklists against the site, plus the bots they were running to find the bounty page in the first place. Real humans evaluating the product were getting drowned out.

The reports followed a template: a generic web checklist run against any SaaS settings page, packaged with a CVSS vector string, OWASP categories, "Business Impact" subsections about regulatory exposure and PR risk, and a screenshot. CVSS scores of 7-and-up on findings that were either UX choices or not findings at all. The volume model is what makes the genre work — send a hundred, get one acknowledgment, screenshot it for credibility, repeat. My inbox was the destination, not the point.

The thread that made the lesson concrete

The clearest version of the pattern came in on a Saturday in March. Subject line: "Bug Report 1 !". Body about 1,400 words, all the right vocabulary, a CVSS v3.1 score of 8.8 rated "High." The underlying claim was a UX hardening suggestion — the kind of thing you find by scanning a settings page with a checklist. Over the next 48 hours, before I had replied, the same address sent five follow-ups, the earliest at 2:58 AM my time.

On Monday I replied once, clearly: this isn't a vulnerability under our policy, here's the threat model, this is our final response. The pushback arrived in three messages over five minutes — OWASP recommendations, Bugcrowd's Vulnerability Rating Taxonomy, a screenshot of a VRT page, none of it addressing the actual threat model. I replied a second time and named the policy.

Four minutes later, the tone changed:

After i reported Then you add this in Our of scope! So it not professionality! I'm waiting for your reply otherwise i will make Good post about Your fruad & scam! Post on linkedin & twitter!!

This is the moment worth naming, because it's also the moment that decides what kind of program you're really running. There was no specific number attached, no Bitcoin address, no "Venmo me and this goes away." Just an implied trade — agree this is a vulnerability, or I post about your fraud. It's a softer extortion than a ransom demand, but it's the same shape: a threat of reputational damage conditioned on you giving up something you don't think they're owed.

Two more follow-ups arrived. I did not respond. They never posted.

Why I could afford to call the bluff

Killswitch is built on the same architectural pattern as 1Password. Private files are zero-knowledge — encrypted in the user's browser, with keys we never see. Shared files (and the whole point of a deadman switch is delivery to a beneficiary) use a wrapped-key model, the same one 1Password uses for Emergency Access: the file key is wrapped for the recipient at share time, and we hold a blob that only the intended beneficiary can unwrap. Either way, the plaintext is not on our side of the wire. That changes the math on a thread like this in two ways.

The worst-case version of almost any claim someone might bring me — a full server breach, a database dump, an S3 bucket walked out the door — leaves the files as ciphertext that neither we nor the attacker can read. The pressure point that works against a normal SaaS ("we'll tell your users you leaked their data") does not load the same way against a service whose entire architecture is "we can't see your data."

A public accusation of "fraud and scam" also lands a little harder against a product whose whole premise is trust-by-architecture, which is the reason engaging is more tempting and the reason engaging is more dangerous. The cryptography is supposed to be the answer. Me arguing with a stranger on LinkedIn is not the answer.

If your product doesn't have that architectural backstop, the calculation is different. Not impossible — most beg-bounty threats never get posted regardless — but different.

What I do now instead

The bounty page is gone. killswitch.app/security/bounty returns a 410 Gone, and every reference to "bounty" has been pulled from anything indexable. The hunters are following a Google query, not a personal grudge — when the query stops returning a hit, the next target is one row down in their spreadsheet, not me. For a solo founder, the right size of bug bounty program turns out to be zero.

In its place:

The Acceptable Use Policy now restricts active security testing — scanning, probing, fuzzing, penetration testing — to active paid subscribers acting in good faith and within scope. Vulnerability reports from free-trial users and non-subscribers are not acknowledged, rewarded, or compensated, and the originating account may be terminated.
The Terms of Service now contain a line I would not have thought to write a year ago: reports paired with payment demands or coercive language will be treated as extortion attempts.
Coordinated disclosure of issues discovered through ordinary, authorized use of the product is still welcome and always will be. The restriction is on active testing — scanning, probing, bypass attempts — against a service the tester does not have permission to test.

What this policy is not: a blanket ban on security research, a substitute for the architecture, or a way to immunize the product from criticism. The architecture is still the architecture. A fence is not a force field. If something is wrong, people should and will say so.

What it is, plainly: a way to draw an identity line between good-faith researchers and drive-by scanners, and to keep a one-person team from being the dumping ground for the latter. Tying active testing to a paid account creates a paper trail and puts the testing inside a contract both sides have signed. It also gives me a one-line answer to anyone who arrives with a "report" and an implied price tag.

For other small founders

Five things I would pass along to anyone running a small product who has not yet seen one of these threads land in their inbox. None of it is novel. All of it was easier to internalize after it happened to me instead of someone else.

The reports are a market, not a referendum. People running beg-bounty at scale are working a funnel. You are one row in a spreadsheet. Reading the email as personal is a category error.
A bounty page is a beacon. The audience you want it to attract and the audience it actually attracts are not the same group, and the ratio gets worse, not better, the smaller you are.
Decide your no-pay policy in writing, in advance. Make the decision once, calmly, when nothing is on fire. A clear public "we do not pay for unsolicited reports" answers the email for you.
Engage at most twice. One technical reply. One follow-up if the first is pushed back on. After that, no further engagement on the merits. Two replies is enough to be fair. A third invites a thread.
Restrict active testing to paying customers. Coordinated disclosure of issues found through ordinary use stays open. Active scanning and probing get gated behind a contract. This is the shape that scales down to a one-person team.

The line between welcoming security research and not running a 24/7 unpaid help desk for the world's checklist-scanners is harder to draw than I expected. I am not convinced I have it in exactly the right place yet. But "no public bounty page, active testing for subscribers only, coordinated disclosure for ordinary use" is much closer to right than where I started.