我构建了 VERDICT：一个能展示评审过程的黑客松平台

A hackathon portal can collect projects, assign judges, and publish scores.

But there is a harder question hiding underneath all of that:

When the results are announced, can anyone understand how they were reached—and verify that they haven’t quietly changed?

That question was the starting point for VERDICT, our submission and judging platform built for DOGFOOD 2026.

We didn’t want to build just another project gallery with a leaderboard attached.

We wanted to build a portal where the entire judging process is inspectable.

🎥 Watch the 5-minute demo:

Project: VERDICT
Stack: Django 5.2, Django REST Framework, PostgreSQL 16
License: MIT
Run locally: docker compose up --build --wait

Source code: [Add your public GitHub repository link here]

The idea: make the whole judging journey visible

A hackathon is really a chain of decisions.

Participants register.
Teams are formed.
Projects are submitted.
Judges review them.
Scores are calculated.
Results are published.

If one step in that chain is unclear, inconsistent, or insufficiently protected, the final leaderboard inherits the problem.

So we designed VERDICT as one connected workflow—from event setup to result verification—rather than a collection of disconnected screens.

The goal was simple:

The portal should not only produce results. It should make those results understandable.

T1: The essentials, done properly

The first layer is everything an organizer and participant expects from a hackathon platform.

Organizers can create events with:

Start and end dates
Tracks
Prizes
Custom submission questions

Participants can create teams using invite links and work on submissions throughout the event.

A project submission can contain:

Tagline and description
Images
Demo video
Repository URL
Live deployment URL
Technology tags
Track
Answers to event-specific questions

Projects remain editable until the submission deadline.

Once the deadline passes, the server rejects late submissions.

That detail is important.

A deadline displayed in the frontend is only a suggestion. A deadline enforced by the backend is an actual rule.

VERDICT treats the submission deadline as a domain constraint, not a UI feature.

The public gallery then makes submitted projects discoverable through search and track filters.

T2: Judging that respects boundaries

The next challenge was judging itself.

Organizers can invite judges and assign projects while considering:

Judge workload
Track scope
Conflicts of interest
Optional anchor projects

Rubrics can also contain weighted criteria, and organizers get a dashboard showing judging progress.

But the most important part is not what judges can see.

It is what they cannot see.

A judge must not be able to inspect another judge's reviews. They also should not be able to access projects outside the tracks they are assigned to.

And those restrictions are enforced on the backend.

Changing a URL does not bypass them.

Calling the API directly does not bypass them.

The authorization rules live where the data is protected—not just where the data is displayed.

That leads to a distinction that is easy to miss when building internal tools:

Hiding data in the interface is not the same as protecting it.

The tricky part: scores aren't the whole story

This was where the project became more interesting.

Imagine two judges evaluating the same set of projects.

One judge tends to give scores around 90.

Another rarely gives anything above 70.

Even when both judges are making reasonable decisions, their personal scoring habits can affect the final ranking.

A naive average treats both scoring styles as directly comparable.

We wanted VERDICT to account for that.

We model a review conceptually as:

observed score = project quality + judge offset + noise

The judge offset captures a judge's general tendency to score higher or lower.

The noise represents the natural variation that exists in individual reviews.

Instead of assuming every raw score is directly comparable, VERDICT can estimate and compensate for systematic differences in judging style.

The point is not to tell a judge what a project should have scored.

The point is to make the final result less dependent on whether a particular judge is naturally stricter or more generous.

That makes the ranking more about relative project quality and less about the quirks of individual scoring habits.

T3: From scores to something people can actually inspect

A leaderboard is easy to display.

A trustworthy leaderboard is harder.

For every result, we wanted the path from submission to ranking to be explainable.

That means being able to answer questions such as:

Who judged this project?

Which rubric criteria were used?

How were the scores combined?

How did judge calibration affect the result?

Did the underlying review data change after judging?

Instead of treating the leaderboard as a final number, VERDICT treats it as the output of a process that can be examined.

This is where the project moves from being a CRUD application to something closer to an auditable system.

T4: Results should be verifiable

There is another problem with published results:

Even if the original calculation was correct, how do you know the underlying data wasn't changed later?

VERDICT addresses this by treating the judging history as something that should be possible to verify.

The system keeps the relevant judging information available as part of the result-generation pipeline, so the published outcome can be traced back to the reviews that produced it.

The philosophy is straightforward:

Don't just show the answer. Show enough of the process to explain the answer.

That principle shaped both the architecture and the UI.

Building it with Django

The backend is built with:

Django 5.2
Django REST Framework
PostgreSQL 16

Django gave us a strong foundation for modeling the domain: events, teams, submissions, judges, assignments, rubrics, reviews, and results.

DRF provides the API layer, while PostgreSQL handles the underlying relational data.

One architectural decision we kept coming back to was this:

Important rules belong in the domain and backend—not only in frontend flows.

Submission deadlines, judge visibility, track boundaries, and permissions all need server-side enforcement because those are business rules, not presentation rules.

What we learned

The most interesting part of building VERDICT wasn't creating another hackathon portal.

It was thinking about what happens after everyone clicks "Submit".

A conventional portal answers:

"What did the judges score?"

A more useful system also answers:

"Why is this the result, and can we verify it?"

That shift changes how you design the application.

Authorization becomes part of the judging model.

Deadlines become backend invariants.

Scoring becomes a data-modeling problem rather than just an arithmetic operation.

And the leaderboard becomes the end of an auditable workflow instead of a number rendered on a page.

What's next

There is still plenty we would like to explore.

More advanced calibration methods could improve consistency across larger judging panels.

We could also expose more of the result-generation process publicly, provide richer audit trails, and make the system easier to operate for hackathons with thousands of participants and judges.

But the core idea will stay the same:

A judging system should be able to show its work.

That is what we built with VERDICT.

Try it yourself

docker compose up --build --wait

Project: VERDICT
Stack: Django 5.2 · Django REST Framework · PostgreSQL 16
License: MIT

Source code: https://github.com/rajj28/verdict

Thanks for reading—and if you're building evaluation, ranking, or judging systems, we'd love to hear how you approach the problem of making results explainable and trustworthy.