If you have ever participated in or organized a hackathon, you already know the open secret: most hackathon judging is an accidental lottery.
A team spends 48 sleepless hours building a brilliant distributed system, only to be evaluated by Judge Alice, who strictly scores every project between a 2.0 and a 3.0. Meanwhile, another team building a simple mock UI happens to draw Judge Bob, who hands out 5.0s like candy on Halloween.
When the raw scores are averaged in an Excel spreadsheet, the second team takes home the grand prize, while the first team walks away wondering what they did wrong.
Worse, most hackathon platforms require bloated cloud subscriptions, break the moment event Wi-Fi stutters, and hide their scoring algorithms behind a proprietary black box.
We built Juryza to solve this once and for all: The self-hosted hackathon platform with judging you can mathematically defend.
Here is a quick look at the live platform across all four key personas: organizer dashboard, blind judge scoring, the Bradley–Terry pairwise duel arena, and the Notion-style participant project editor:
⚡ Quick Links & Live Demonstration 🐙 GitHub Repository: https://github.com/sanjaysah101/Juryza 🎥 YouTube Demo: https://youtu.be/gfsorn4lWI 💻 Live Local Stack (100% Offline Capable):
Open http://localhost:8080 — no cloud account, no credit card, and zero external network calls required at runtime. The boot sequence spins up PostgreSQL 18 and Next.js 16, runs tracked Drizzle migrations, and seeds: The DOGFOOD Fixture Event: 41 projects, 30 judges, 126 scores, duplicate submissions, and edge-case calibration data. A Live Sandbox Event: Submissions open so you can register, create a team, and write projects immediately. Hackathon Raptors Real Showcase (Opt-in): 31 real-world hackathons with authentic placements (SEEDSHOWCASE=1 docker compose up).
| Role | Email | Password | What You Can Test | | :--- | :--- | :--- | :--- | | Organizer | organizer@juryza.test | organizer-password-123 | Rubric weighting, judge assignment planner, conflict-of-interest detection, integrity dashboard | | Judge A | judge.a@juryza.test | judge-a-password-123 | Blind rubric scoring console & keyboard-navigated pairwise duel arena | | Judge B | judge.b@juryza.test | judge-b-password-123 | Proves absolute blind isolation (Judge B gets 403 on Judge A’s scores) | | Participant | participant@juryza.test | participant-password-123 | Notion-style block editor, slash menu, autosave, team invites | | Admin | admin@juryza.test | admin-password-123 | User roles, audit logs, system-wide controls |
We designed Juryza around a single foundational constraint: A hackathon platform must survive in a basement with zero internet connectivity.
The Tech Stack Framework: Next.js 16 (App Router, React 19, React Compiler) Database & ORM: PostgreSQL 18 with Drizzle ORM in an isolated monorepo workspace (packages/database) Authentication: Better Auth with local email/password sessions, admin controls, and per-event permission hierarchies Rich Text Engine: Tiptap 3 with custom slash commands, floating toolbar, markdown shortcuts, task items, and autosave Design & UI: Tailwind CSS v4 + shadcn/ui on Base UI primitives Monorepo & Tooling: Bun + Turborepo + Biome
Most hackathons fail because arithmetic averages confuse judge calibration with project quality. Juryza introduces three distinct, mathematically rigorous evaluation layers: Cross-Judge z-Score Normalization
Judges systematically differ in two ways: Level Bias ({% katex inline %}\mu{% endkatex %}): Some judges are harsh (averaging 2.5); others are generous (averaging 4.2). Spread Bias ({% katex inline %}\sigma{% endkatex %}): Some judges use the entire scale (1–5); others cluster tightly between 3 and 4.
{% katex %} \text{normalized} = \text{clamp}\left(\text{globalMean} + z \times 0.9, 1, 5\right) {% endkatex %} Flat Judge Handling: If a judge gives every single project the exact same score, their variance is zero ({% katex inline %}\sigmaj \le 10^{-9}{% endkatex %}). They provide zero ranking information. Juryza automatically sets their {% katex inline %}z = 0{% endkatex %}, mapping them to the global mean so they neither artificially inflate nor penalize the teams they saw. The Epsilon Division Bug: During fixture verification, we uncovered a critical floating-point trap: when a judge assigns identical scores, floating-point arithmetic produces a standard deviation around 1e-16 rather than 0.0. A naive if (sd > 0) check caused division of noise by noise, unfairly tanking projects in the leaderboard! We hardened this with strict epsilon tolerances and regression test suites. Bradley–Terry Pairwise Duel Arena
When judges only review 2 or 3 projects, variance estimates ({% katex inline %}\sigma{% endkatex %}) can be noisy. For high-stakes rounds, Juryza features a Pairwise Duel Arena.
Instead of awarding arbitrary numbers, judges are shown two projects side-by-side and pick the stronger one.
Under the Bradley–Terry model, the probability that project {% katex inline %}i{% endkatex %} beats project {% katex inline %}j{% endkatex %} is:
We fit project latent strengths {% katex inline %}si{% endkatex %} using Hunter’s (2004) Minorization-Maximization (MM) algorithm: