Trust the Result: Building ForgeJudge in 72 Hours

anandrajput0210 — Thu, 08 Oct 2026 16:19:28 +0000

Building ForgeJudge in 72 Hours: Trust the Result

What if the platform responsible for judging a hackathon was itself the thing you had to build?

That was the challenge behind ForgeJudge, the project I built during the DogFood 2026 hackathon.

The goal wasn't simply to create another hackathon management platform. I wanted to build a system that could handle the difficult parts of judging: assignments, role isolation, scoring, progress tracking, normalization, and leaderboard results.

And, as expected, some of the hardest problems weren't the ones I expected at the beginning.

The Problem

Hackathons have a surprisingly complicated judging workflow.

Participants submit projects. Organizers assign judges. Judges score projects using weighted criteria. The system needs to prevent judges from accessing other judges' assignments, calculate results correctly, track progress, and eventually produce a leaderboard.

So the real question became:

Can I build a judging system where the result isn't just calculated, but can actually be trusted?

I built ForgeJudge around that question.

What I Built

ForgeJudge is a hackathon judging and management platform built as a modular monolith.

The main stack was:

React for the frontend
FastAPI for the backend
PostgreSQL for persistent data
Docker Compose for the development environment

The platform includes functionality for:

Authentication
Events and tracks
Teams
Projects
Project submissions
Judge invitations
Judge assignments
Weighted rubrics
Score submission
Judge progress tracking
Organizer judging progress
CSV judging export
Score normalization
Leaderboards
Role-based access control

The architecture was intentionally kept relatively simple because the priority during a 72-hour hackathon was to build a working system rather than introduce unnecessary complexity.

The 72-Hour Constraint

The first challenge was time.

During a 72-hour hackathon, there isn't much room for perfect architecture diagrams, extensive refactoring, or rebuilding everything every time something goes wrong.

I had to make decisions quickly.

One thing that became particularly important was Git.

Instead of treating GitHub as something to do at the end, I used Git as a safety net throughout development.

The basic cycle was:


bash
git status
git add .
git commit -m "Describe the change"
git push

DEV Community: anandrajput0210

Trust the Result: Building ForgeJudge in 72 Hours

Building ForgeJudge in 72 Hours: Trust the Result

The Problem

What I Built

The 72-Hour Constraint