Everyone builds the same thing: a submission and judging platform for hackathons.
Hackathon Raptors has run 35 hackathons across 85+ countries since 2023. They have seen the same problems appear again and again: registrations, teams, submissions, judge assignments, scoring, normalization, results, certificates, and exports all becoming separate pieces of an increasingly messy workflow.
At a glance 🌍 Online and global ⏳ 72 hours 💰 $2,500 prize pool 👥 Solo or teams of up to 4 💸 Free to participate 🔓 Open source 🐳 Self-hosted 🛠️ Build with the stack of your choice
The winning project is intended to be forked, self-hosted, and used for actual Hackathon Raptors events.
So instead of building a demo that gets abandoned after the weekend, you are building something that could become real infrastructure.
The difficult part is making the entire system reliable when real people start using it.
Two judges can look at the same project and give completely different scores. One might give almost everything a 4 or 5. Another might rarely give anything above a 3.
Simply averaging those scores can produce a ranking that reflects the judges' scoring habits instead of the quality of the projects.
If a judge can make an API request and retrieve another judge's ballot, the system has failed.
Behind that simple flow is a much larger pipeline: Registration Teams Submissions Eligibility Judge assignment Scoring Normalization Results Certificates Archive
You need: Authentication and sessions Visitor, participant, judge, organizer, and admin roles Event creation Configurable dates, tracks, and prizes Team formation through invite links Project submission Draft and edit support until the deadline Actual deadline enforcement Public project gallery Search and filtering
The submission system should support the usual project information: Project name Tagline Long description Thumbnail Image gallery Demo video URL Repository URL Live link Technology tags Track Organizer-defined custom questions
T2 requires: Judge invitations Judge assignments Batch or algorithmic assignment Weighted judging rubrics Backend-enforced role isolation Judge progress tracking Cross-judge score normalization CSV exports
Organizers should be able to define criteria and give those criteria different weights.
This includes: Community voting Configurable voting access Open-link voting Email-gated voting Authenticated voting Comments on projects Hidden results during the voting window Randomized project ordering Rate limits Duplicate detection Readable audit trails
The brief mentions quadratic voting as one possible approach, but teams are free to implement something else if they can defend it.
It is whether you thought about how people can abuse the voting system and what your platform does about it.
The requirements include: REST API Webhooks API access for UI actions Certificate generation Record generation Signed and publicly verifiable judge participation records Embeddable gallery widget Bulk import and export