Winnable

Open hackathons, ranked by your odds of winning cash.

Comment

Inspiration

Devpost sorts hackathons by prize or deadline, so the biggest number wins your attention. When I looked at the field behind the prizes, the order fell apart. On 18 October, Amazon's hackathon paid USD 128,000 in cash to a field of 56,798 registrants: an average entry had a 1 in 857 chance of winning any of it. Meta's VR competition, open to the same people, paid USD 1,000,000 across 20 cash prizes to 3,385 registrants: 1 in 64. Eight times the prize, thirteen times the odds. Even this hackathon, the one I am entering, is 1 in 311. The prize tells you nothing; the field tells you everything, and nobody shows you the field before you spend a weekend.

What it does

Winnable reads every open Devpost hackathon each day and ranks them by your odds of winning cash.

  • Odds per hackathon. "1 in 64" means one cash prize for every 64 expected submissions, with the arithmetic shown in a receipt: registered today, projected by the deadline, expected to submit, cash prizes, chance, expected cash per entry.
  • Calibrated, not guessed. Most registrants never submit. Winnable learned how many do from 150 finished Devpost hackathons (registrants against projects in their galleries). The median is 28 %; the fitted curve is submissions = 0.41 × registrants^0.90, shown in the app under "How the odds work".
  • Cash only. Credits, gift cards, licences and swag are listed but never counted. Devpost's own "in cash" label is checked against the prize's words: a "$5,059 in cash" prize that is really Deployxa credits counts as $0, with the reason shown.
  • Can you enter. Country, age, student status and team are checked against each hackathon's eligibility list. What you cannot enter drops to "Not for you" with a plain reason: "In person: Singapore", "Invite only", "Not open in Brazil".
  • Fields still growing. Registrations keep coming, so the field is projected to the deadline. Hackathons in their first fifth wait under "Opening soon" without odds, so four registrants on day one never read as 1 in 1.
  • Fits your GitHub, and your calendar. Optionally match your public repos to hackathon themes, and put your five best deadlines in your calendar in one click.
  • Works on a phone. The same board, receipt and reasons, sized for a thumb.
  • Private by design. No accounts. The profile stays in your browser; the only outside request is the optional GitHub lookup.

Who it is for: student builders who ship side projects fast with AI agents and want prize money for a weekend's work. They have a handful of free evenings a month and a GitHub full of repos; today they scroll 180 hackathons sorted by prize, open the big ones, and only find out in the rules that they are excluded, that the field is enormous, or that the "prize pool" is credits.

How I built it

Planned and built with Claude Code and the Devpost Learn skill pack, from an empty folder during the submission period. The planning trail is in the repo: devpost/scope.md, prd.md, spec.md, the build checklist.md with every place the build proved the plan wrong, and app-map.html, a code tour.

  • A Python collector (standard library plus curl, because Devpost refuses Python's own HTTP client) reads the Devpost API and every hackathon page, parses prizes and eligibility, fits the calibration and writes one JSON file. A GitHub Action runs it every morning.
  • A static board in vanilla JavaScript ranks and explains everything in the browser. Pure ranking functions are tested in Node; a Playwright click-through checks desktop, dark mode and phone for console errors.
  • Deployed as a Cloudflare Worker with static assets.

Challenges I ran into

Real data kept proving the plan wrong, and each time the fix went into the checklist with a test:

  • 130 of the first 179 hackathons had not opened yet; a hackathon that opened that morning ranked first on four registrants. Fix: project the field from the elapsed share of the submission period, and hold back the first fifth.
  • Prize lines lied in both directions: "$2,000 and $100 each to 20 people" was read as USD 40,000; a "USD 9,117 in cash" pool was USD 88 of cash; 300 participation awards made the odds 1 in 1. Fix: read multipliers from the prize text, check "in cash" against the prize's own words, exclude participation prizes.
  • The real eligibility lists had eleven kinds of rule, not the four planned (university vs high school, age ranges, team required, member-only events).

Accomplishments I'm proud of

  • The odds are honest enough to argue with: every number shows its arithmetic, and the calibration scatter is in the app.
  • It answers a real question in one screen. On 18 October, of 68 hackathons open on Devpost, a Swiss university student with a team could enter 25 with a field big enough to rate, plus 33 opening soon or just opened, and could see at a glance which was worth the weekend.

What I learned

  • Write the riskiest assumption down before building on it. Everything in Winnable rests on one guess: how many registrants actually submit. The spec named it as the open question on day one; five finished hackathons gave rates from 24 % to 53 %, too wide to trust, so the build fitted 150 and put the scatter in the app instead of hiding it.
  • Real data is the best reviewer of a plan. The plan broke four times on contact with real Devpost pages: hackathons that had not opened yet, prize text that inflated or disguised cash, eligibility lists with eleven kinds of rule instead of four, and a 1,000,000-dollar competition that topped an "expected cash" sort. Each break became a recorded revision and a test, so the plan stayed honest instead of drifting.
  • Planning with an agent is a conversation about decisions, not a prompt. The skill pack's scope, PRD and spec forced the cuts to be explicit (no accounts, no backend, one data file), which is why the whole product fits in a static page and a daily job.
  • Verify like a stranger would. Tests for the maths, a browser click-through on desktop, dark mode and phone, and a judge-style review round caught what reading the code did not: a first-time visitor who saw zero hackathons, and credits counted as cash.

What's next for Winnable

From the PRD's later list: other money sources (grants, bounties, EU calls), odds per prize track, a skill multiplier learned from your own past results, team formation for team-only events, and a history of how each hackathon's odds moved as registrations grew.

Links

Built With

Share this project:

Updates

Submission history