Registrations are not submissions
Microsoft's AI Agents Hackathon 2025 had over 18,000 registered developers and 570 project submissions. That gap is normal. A big registration number creates reach, but organizers still judge the projects that actually land.
Opportunity Hack's field report puts numbers on the same problem. It reports an average completion rate of 26.5 percent and says recent events improved to 30 to 40 percent after deliberate design. The organizer problem is not getting people excited. It is getting them to ship.
Team formation changes the judging load
Opportunity Hack says teamed registrants submitted at 39.7 percent, people looking for a team at 17.8 percent, and solo hackers at 9.8 percent. It also says teams of three or more shipped 93 percent plus, while solo projects shipped 46 percent of the time.
From the organizer side, this means better team formation is not just nicer community management. It produces more complete submissions, more demos, and a more predictable judging queue.
MLH wants science-fair judging
MLH's judging plan says judging is often the biggest pain point for organizers, then recommends science-fair style judging. Teams stay at assigned tables, judges walk to them, ask questions, and score projects as they go.
MLH also recommends holding judging in person where possible. It says judging rooms can be unfair because each room only sees a subset of projects, then finalist teams may need to re-pitch from judge memory and notes. Science fair makes the process more comparable.
The math decides how many judges you need
MLH says judging usually takes around 2 to 3 hours depending on submissions and judges. For the 2026 season, it observed an average submission rate of one project per four checked-in hackers.
Its example uses 175 submitted projects, three rounds per project, four minutes per project per judge, and two hours of judging. The result is 18 judges. That is why organizers ask for short demos and strict timing. The schedule is not arbitrary.
Judges need artifacts, not lore
MLH recommends hackers submit 2-minute videos on the submission platform. It says the video should be a demo of the hack, not a presentation, and can serve as a reference during final deliberations or later on resumes.
Devpost's judging criteria guide says judges look at eligibility, required tools, required URLs, demo access, technological implementation, ease of use, potential impact, quality of idea, design, and presentation. Your project page should make those checks boring.
Cheating checks happen before the announcement
MLH's cheating check guide says organizers should check all winning projects regardless of event type, and that cheating is more common for digital events. It tells organizers to assume non-malicious mistakes first, then dig deeper when signals look wrong.
The checklist includes GitHub start times, one big commit at the beginning, readmes mentioning another event, whether every team member contributed, solo hackers with unusually advanced weekend projects, video timestamps, video publish dates, and old Devpost submissions that look similar.
Win by reducing organizer risk
When organizers are tired, the clean project wins trust. Public repo. Clear README. Working URL. Short demo. Track label. Required SDK proof. Team members listed. No mystery assets. No private video.
That does not mean the safest idea wins. It means the organizer can defend your win. Build something sharp, then make the evidence easy enough that a judge can score it and an organizer can announce it without fear.
< read by a human · updated as things change >
browse hackathons