Trust the Result: Building ForgeJudge in 72 Hours

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