More code is being written by AI than ever before. A lot of it ships with problems that AI can't diagnose, let alone fix. Race conditions, broken edge cases, logic that passes CI but fails in production. The bugs are subtle because the code looks right.

Maintainers know something is wrong. They don't always have time to fix it. That's where you come in.

How bounty.new works

A maintainer posts a bounty on a bug or feature. They fund it through Stripe. The money is held until the work ships.

You find a bounty that matches what you know. You write the fix, open a PR, and run /submit in the issue thread. Our GitHub bot links your submission to the bounty and notifies the maintainer.

The maintainer reviews your PR. If the work is merge-worthy, they run /approve. Payment releases to you directly. If it's not ready, you get review feedback and can iterate. The bounty stays open until someone ships it.

Why this works for developers

Every bounty is scoped. You know the problem, the codebase, and the payout before you write a line of code. No spec drift, no ambiguity about whether your contribution will be accepted or ignored.

You get paid for the thing open source has always asked you to do for free: read someone else's code, understand the real problem, and write a fix that holds up.

What we look for

People who read the issue before they open a PR. Developers who can explain their approach in review and respond to feedback. The kind of contributor maintainers actually want to hear from.

If your workflow is "paste the issue into an LLM and submit whatever comes back," this isn't for you. If you're the person who fixes what that workflow produces, it is.

Blog

AI writes the bugs. You fix them. Get paid.

Introducing Bounty.new