Tanya Garg

Posted on Oct 8

JUDGELAYER: Building a Hackathon Judging Platform You Can Actually Trust

#devchallenge #security #softwaredevelopment

JUDGELAYER: Building a Hackathon Judging Platform Where Trust Is Part of the Product

Hackathons are exciting.

Hundreds of people build projects, teams submit their ideas, judges review them, and eventually someone wins.

But there is a part of hackathons that doesn't get talked about enough:

Can we actually trust the judging process?

Who can see a submission?

Can one judge see another judge's score?

Can a participant access private judging data?

What happens when the event is over and organizers need to understand how a result was produced?

These questions became the starting point for our DOGFOOD 2026 project:

JUDGELAYER

Run the event. Protect the judging. Trust the results.

Instead of building another generic hackathon management dashboard, we wanted to build something around the trust layer behind judging.

💡 The Idea

Our goal was simple:

Create a self-hosted platform that manages the complete hackathon submission and judging workflow while keeping access controlled and auditable.

The workflow looks like this:

SUBMIT
  ↓
ASSIGN
  ↓
REVIEW
  ↓
PROTECT
  ↓
AUDIT
  ↓
EXPORT

There are four main types of users:

Visitor — explores public projects
Participant — submits and manages a project
Judge — reviews assigned projects
Organizer — manages the event, judging and results

The interesting part isn't just that each role has a different dashboard.

The important part is that the backend actually enforces what each role is allowed to access.

🎯 Why We Didn't Want a Normal Dashboard

While planning the project, it was tempting to build the usual hackathon platform:

Projects → Judges → Scores → Leaderboard

But that didn't feel enough.

A beautiful interface can hide a serious security problem.

For example, hiding a "View Score" button doesn't mean the score is protected.

If a participant can directly call an endpoint and retrieve judge data, the application isn't secure.

So we made role isolation one of the core architectural principles of JUDGELAYER.

The UI communicates the permissions.

The backend enforces them.

🧩 The Trust Layer

This became the main idea behind our product.

Inside the platform, we wanted users to understand the current security state without making the interface feel complicated.

For example, a judge can see:

TRUST LAYER

✓ Assigned projects only
✓ Peer scores hidden
✓ Participant judging data protected
✓ Review actions audited

This is not just decorative UI.

The actual authorization logic lives on the backend.

That distinction was important to us.

👀 The Public Experience

We started with the simplest role: a visitor.

No login should be required just to explore an event.

The public gallery lets visitors discover projects and open their public submission information.

A project can contain things like:

Project name
Description
Team
Repository
Demo
Presentation

The idea is to keep the public experience open while keeping private judging information behind the appropriate access controls.

📝 Participant Workflow

Next comes the participant.

A participant gets their own submission workspace where they can manage their project.

We also added a Submission Health Check concept.

Before submitting, the platform can show whether important fields are ready:

SUBMISSION HEALTH

✓ Project name
✓ Description
✓ Repository
✓ Demo
✓ Presentation

READY TO SUBMIT

This sounds like a small feature, but it improves the actual submission experience.

Instead of discovering a missing field after submitting, the participant gets feedback before the submission enters the judging pipeline.

⚖️ The Judge Experience

This is where JUDGELAYER really starts to become different.

When a judge logs in, they don't get access to every project's private judging information.

They get a controlled queue of their assigned projects.

A judge can:

Open an assigned project
Review the project evidence
Evaluate judging criteria
Add supporting notes
Submit the review

The interface also makes the judge's scope clear.

YOUR JUDGING SCOPE

Assigned projects only
Peer scores hidden
Private judging data protected
Actions audited

The goal was to make judging feel like a focused review workspace rather than another admin panel.

🔐 The Security Test

One of the most important things we wanted to demonstrate wasn't a UI animation.

It was an actual access-control test.

Imagine Judge A is reviewing Project 42.

Judge B has also reviewed Project 42.

Judge A should not be able to retrieve Judge B's private score.

So we test it.

Judge A
   ↓
Request Judge B's score
   ↓
ACCESS DENIED

The important part is that this isn't simply:

"We removed the button."

The backend rejects unauthorized access.

The same principle applies to participants attempting to access private judging information.

This is what we mean when we say:

Role isolation is enforced by the backend, not just represented by the UI.

🧑‍💼 Organizer Command Center

Organizers need a completely different view.

They need to understand what is happening across the event.

The organizer dashboard brings together:

Submission tracking
Judge management
Project assignments
Review progress
Results
Audit information
CSV exports

One feature we particularly liked was the Judge Coverage view.

For example:

PROJECT #042

Judge 01     ✓ Reviewed
Judge 04     ✓ Reviewed
Judge 07     ◐ Pending

Coverage: 2 / 3

This gives organizers an immediate understanding of which projects still need attention.

🕵️ Auditability

Security isn't only about blocking something.

It is also about being able to explain what happened.

That's why JUDGELAYER includes an audit trail.

Instead of showing a completely raw log, we wanted the events to be understandable:

18:42:09
JUDGE-07
Opened Project #042

18:44:31
JUDGE-07
Submitted Review

18:44:32
SYSTEM
Score recorded

18:44:33
ACCESS CONTROL
Unauthorized score access blocked

This creates a timeline of the judging process.

After the event, organizers don't just see the final result.

They can understand the important actions that happened along the way.

🏗️ How We Built It

We kept the architecture intentionally simple and self-hostable.

Frontend

React
TypeScript
Vite
Tailwind CSS
shadcn/ui

Backend

FastAPI
Python
SQLAlchemy
Pydantic

Database

SQLite

Deployment

Docker
Docker Compose

The goal was to make the entire platform runnable locally without depending on external cloud services.

That also made the project easier to test with seeded fixture data.

🔄 Architecture

At a high level, the system looks like:

                ┌─────────────────┐
                │     FRONTEND    │
                │    React + TS   │
                └────────┬────────┘
                         │
                         ▼
                ┌─────────────────┐
                │      API        │
                │    FastAPI      │
                └────────┬────────┘
                         │
              ┌──────────┼──────────┐
              ▼          ▼          ▼
        AUTH / RBAC    JUDGING     AUDIT
              │          │          │
              └──────────┼──────────┘
                         ▼
                  ┌─────────────┐
                  │   SQLite    │
                  └─────────────┘

The key design principle is:

Authorization happens before sensitive data is returned.

🎨 Designing the Interface

We also didn't want JUDGELAYER to look like a generic hackathon admin panel.

So we created a visual concept around a Trust Command Center.

Instead of filling the screen with dozens of cards, the interface uses:

Strong typography
Thin borders
Compact system metadata
Status indicators
Clean data tables
Focused dashboards
A central Trust Layer concept

The UI should communicate:

Security. Control. Transparency.

Not just:

"Here are some statistics."

🧪 Testing the Important Flows

We focused our testing around the workflows that matter most.

For example:

  Public Gallery
      ✓

Fixture Project Visible
      ✓

Closed Event Rejects Submission
      ✓

Judge Reads Own Score
      ✓

Judge Cannot Read Peer Score
      ✓

Participant Cannot Read Judge Score
      ✓

Organizer Can Export CSV
      ✓

These aren't just visual features.

They represent actual acceptance scenarios for the platform.

🤖 AI Helped Us Build Faster — But the Product Had to Work

Like many modern development projects, we used AI-assisted development during the build.

But we didn't want the result to be:

"AI generated a dashboard."

The real test was whether the application could actually perform the workflows we designed.

So we treated AI as a development accelerator — helping with implementation, debugging, UI iteration and documentation — while the final product still had to be tested through the actual application.

That's why our demo focuses on real screens and real interactions, rather than only showing mockups.

🚧 What We Learned

The biggest lesson from building JUDGELAYER was that security is not a page you add at the end.

It affects the entire application.

The moment you introduce multiple roles, you have to think about:

What data can this user see?
What actions can they perform?
What happens if they directly call an API?
What should be recorded?
What should remain private?

Thinking about these questions early changed the way we designed both the backend and the interface.

🚀 What's Next?

JUDGELAYER could eventually grow beyond a DOGFOOD submission.

Some directions we'd like to explore include:

More advanced judge conflict management
Better review analytics
Custom judging criteria
Multi-stage judging
Review calibration
More detailed audit exploration
Organization-level event management

But the foundation would remain the same:

Keep the judging process controlled, transparent and trustworthy.

🏁 Final Thoughts

Building JUDGELAYER made us look at hackathons from a slightly different perspective.

We usually focus on:

Who built the best project?

But before we can answer that question, we need to trust the process that produces the answer.

That's what JUDGELAYER is about.

Not just collecting submissions.

Not just assigning judges.

Not just calculating scores.

But creating a system where every role has the right access, every important action can be traced, and the final results can be trusted.

Submit.
Assign.
Review.
Protect.
Audit.
Export.

That's JUDGELAYER.