I made a hackathon where 2,500 participants could predict how they'd be judged.
LIKELION's 14th national hackathon 'ANIMAL LEAGUE', with 2,500 participants from 80 universities, run from planning through the finals
- Period
- Jun – Aug 2026
- Role
- Community Manager Intern · Planning & Ops
- Status
- Completed · Finals Aug 2026

Summary
With 314 teams competing, participants couldn't tell what to submit or how it would be judged, and the staff were answering inquiries by hand for three hours a day. I mapped submission items 1:1 to judging criteria so scoring became predictable, structured the guide in the order participants live it, and had an FAQ bot answer instantly. For the finals I built the console (Next.js · Supabase) from the DB schema up so judges' votes showed on the stage screen as they came in.
Impact
- participant inquiries · 80.8% of 229 answered instantly · none unanswered
- 3 hrs/dayto15 min/day
- finals reveal · 2.2 s from vote to stage screen
- Tally, then PPTtoOn screen as votes land
- submission checks · 5 violating teams caught
- Manual checkstoOne full scan
Background
- The largest LIKELION hackathon to date: 80 universities, 2,500 participants, 314 submitting teams (562 repos) → an 8-team finals tournament picking one winner. As a community manager intern I took it from planning through the finals: the feature specs, warm-up sessions, participant guide, and judging policy were made with the team, and I built the 3 ops tools and ran the finals on site myself. (Jun 2026 – Aug 25, 2026; finals at COEX Magok)
- Every collision point between participants, judges, and partners needed a rule — and verifying 562 repos or running a live tournament for 2,500 people was not a manual job.
Execution
Co-planned the Pre-event Work — Platform Specs & Warm-up Sessions
- Co-wrote two feature specs for the hackathon community platform (central and inter-university) with the team and handed them off to the dev (AXP) and design (BD Lab) teams. Each item followed As-Is → To-Be → expected output → detailed spec, with ops decisions separated from dev items.
- Included a 5-level permission matrix (platform admin / lead staff / staff / participant / non-participant), a team-building redesign replacing 'no team, no submission' with member registration at submission, and a register → approve → publish workflow with status badges.
- Co-planned a 3-part warm-up series — problem discovery → MVP scoping → hands-on AI development — defining boundaries and takeaways per session to avoid overlap between speakers.
Co-designed the Judging Policy & Process
- Designed the 3-stage judging funnel (60 teams by docs → 8 by track pitching → 1 by tournament) and the 100-point common rubric (problem definition 25 · feasibility 20 · market 15 · UI/UX 10 · delivery 10 · track fit 20).
- Mapped submission items (problem/features/market) 1:1 to judging criteria, so teams could predict how what they wrote would be scored.
- Fairness rules: script-reading scores zero on delivery, all pitches on operator-provided devices, bracket and order drawn live and locked.
Submission Integrity — Built check.py Myself
- Enforcing 'no edits after deadline' meant checking 562 repos across 314 teams. I built check.py with Claude — it sweeps every branch of every repo for post-deadline commits, and snapshot-JSON comparison catches force-pushes, deleted branches, and public-to-private flips.
- The verdict criteria were agreed before scanning: feature-level code changes = disqualification / README-only edits = deduction / just-past-deadline commits = leniency. The tool only presented evidence in an Excel report; the ops meeting made the calls.
Finals Tournament Console — Built & Operated
- A web app with three role-based views (Next.js · React · Supabase): a stage screen (live bracket, reveal effects), a judge view (winner pick + comment), and an ops console (match control, bracket draw, result reveal).
- The design premise: an irreversible live event. Judge allowlist (off-list submissions rejected server-side — fake votes can't mix in even if the code leaks), no rollback after reveal (mandatory confirm dialogs instead), a backup mode that advances the bracket on operator input alone during network failure, and no auto-decision on ties — a human rules.
- SPEC.md served as the single source of requirements, with a launch procedure of feature freeze → rehearsal → code/PIN rotation → reset. I wrote and shipped the ops runbook through v8; measured console-to-stage-screen latency was 2.2 seconds.
- Stage effects (reveal card animation, finals countdown into the winner scene) were synced with the sound team's and MC's cue sheets. The timer was cut from the app and delegated to a separate venue screen — a deliberate scope reduction.
Participant Comms, FAQ Bot & Partner Ops
- Co-wrote the Notion guide that 2,500 participants referenced for a month — structured by participant journey (team building → build → judging → venue), with every change dated and traceable.
- Built and ran a Discord bot over the 78-item FAQ: keyword matching first (zero cost) with LLM fallback, a strict no-fabrication policy (unknowns route to staff), and a daily unanswered-question report — with humans deciding what gets added. Over a month it answered 229 questions from 53 users — 80.8% via instant keyword match, 0 unanswered.
- Ran the 8-partner tool support program (unified deadlines, team-lead submission, billing-risk notices), and communicated directly with OpenAI in English — tracking credit issues and landing a finals technical judge.
314 teams
submitted · 562 repos · 80 universities
60 teams
100-point document review · 15 per track
8 teams
5-minute track pitch + Q&A · 2 per track
1 team
1:1 three-round live tournament before 2,500
Nearly half the points went to problem definition (25) and feasibility (20). Submission items mapped 1:1 to criteria, so teams could predict how they'd be scored.
Hypothesis
Some teams commit after the deadline, and 562 repos can't be checked by hand
Agree criteria
Code change = DQ · README = deduction · just-late commit = leniency
Full scan
Every branch swept for late commits, force-pushes, private flips
Evidence
Results go to the staff meeting as a spreadsheet; no automatic verdicts
People decide
5 violations found; 2 disqualified under the graded criteria
Criteria were agreed before scanning and the tool only presented evidence, so the five violations were judged against a standard everyone had accepted.
Results
- The full 562-repo sweep found 550 clean and 5 violating teams — 2 disqualified under the graded criteria, the rest handled with deductions or leniency.
- Ran the finals tournament (8 teams, 5 judges) end-to-end on the console I built.
- LIKELION's Brand Design Lab published 'ANIMAL LEAGUE' as a Behance case study, with me credited as a collaborator.
What I learned
- Enforcing 'no edits after deadline' needed a checking tool, but I judged that participants would struggle to accept verdicts handed down by a tool. We agreed on graded criteria for each kind of violation before the sweep, and the tool only produced evidence.
- For a live-event tool, I decided to close the irreversible situations before adding features: no-rollback reveals, a network backup mode, ties delegated to humans. Those safeguards are what let the crew run finals day with confidence.
- The guide, FAQ, bot, and inquiry channels were really one system. Designating a single source of truth and making everything else reuse it reduced the 'same question, different answer' failure.
On site






