Most hackathons ask you to build whatever you want.
Dogfood 2026 does the opposite.
Everyone builds the same thing: a submission and judging platform for hackathons.
The challenge is simple:
Build the platform that will judge you.
And there is a reason this is more interesting than it sounds.
Hackathon Raptors has run 35 hackathons across 85+ countries since 2023. They have seen the same problems appear again and again: registrations, teams, submissions, judge assignments, scoring, normalization, results, certificates, and exports all becoming separate pieces of an increasingly messy workflow.
Now they want to build the platform they actually wish they had.
That is what Dogfood is about.
About the Hackathon
Dogfood 2026 is a 72-hour online hackathon organized by Hackathon Raptors.
The event runs from September 25 to September 28, 2026.
At a glance
- 🌍 Online and global
- ⏳ 72 hours
- 💰 $2,500 prize pool
- 👥 Solo or teams of up to 4
- 💸 Free to participate
- 🔓 Open source
- 🐳 Self-hosted
- 🛠️ Build with the stack of your choice
But this is not a normal platform-building challenge.
The winning project is intended to be forked, self-hosted, and used for actual Hackathon Raptors events.
So instead of building a demo that gets abandoned after the weekend, you are building something that could become real infrastructure.
Why Build Another Hackathon Platform?
Hackathon platforms already have most of the features organizers expect.
Registration.
Team formation.
Project submissions.
Public galleries.
Judge scoring.
Community voting.
Organizer dashboards.
CSV exports.
So what is missing?
The difficult part is not building another CRUD application.
The difficult part is making the entire system reliable when real people start using it.
Consider judging.
Two judges can look at the same project and give completely different scores. One might give almost everything a 4 or 5. Another might rarely give anything above a 3.
Simply averaging those scores can produce a ranking that reflects the judges' scoring habits instead of the quality of the projects.
Then there is access control.
A judge should see the projects they are assigned to.
They should not see another judge's scores.
They should not see another track's submissions.
And hiding those things in the frontend is not enough.
If a judge can make an API request and retrieve another judge's ballot, the system has failed.
These are the problems Dogfood wants teams to solve.
Running a Hackathon Is a Data Problem Wearing a Party Hat
A hackathon looks simple from the outside.
Someone registers.
Teams form.
Projects get submitted.
Judges score them.
Winners are announced.
Behind that simple flow is a much larger pipeline:
- Registration
- Teams
- Submissions
- Eligibility
- Judge assignment
- Scoring
- Normalization
- Results
- Certificates
- Archive
Each stage has its own state and data.
Each stage feeds the next one.
If something goes wrong, the problem eventually reaches judging.
And judging is the part participants actually care about.
Dogfood asks you to build the system that manages this entire lifecycle.
The Tier Ladder
There are no tracks in Dogfood.
There is one product and four tiers.
The goal is to climb the ladder while keeping everything you build correct.
T1: Core
T1 is the foundation.
A submission that does not clear T1 is not judged.
You need:
- Authentication and sessions
- Visitor, participant, judge, organizer, and admin roles
- Event creation
- Configurable dates, tracks, and prizes
- Team formation through invite links
- Project submission
- Draft and edit support until the deadline
- Actual deadline enforcement
- Public project gallery
- Search and filtering
The submission system should support the usual project information:
- Project name
- Tagline
- Long description
- Thumbnail
- Image gallery
- Demo video URL
- Repository URL
- Live link
- Technology tags
- Track
- Organizer-defined custom questions
This is the minimum.
It is not the target.
T2: Judging
This is where the interesting engineering starts.
T2 requires:
- Judge invitations
- Judge assignments
- Batch or algorithmic assignment
- Weighted judging rubrics
- Backend-enforced role isolation
- Judge progress tracking
- Cross-judge score normalization
- CSV exports
The weighted rubric is especially important.
Organizers should be able to define criteria and give those criteria different weights.
More importantly, the backend needs to enforce who can see what.
A judge should never be able to access another judge's scores.
A track judge should never be able to access another track's data.
If the only protection is a hidden frontend button, it does not count.
The authorization needs to hold up when someone calls the API directly.
T3: Public
T3 focuses on community participation.
This includes:
- Community voting
- Configurable voting access
- Open-link voting
- Email-gated voting
- Authenticated voting
- Comments on projects
- Hidden results during the voting window
- Randomized project ordering
- Rate limits
- Duplicate detection
- Readable audit trails
You can also go beyond one-person-one-vote.
The brief mentions quadratic voting as one possible approach, but teams are free to implement something else if they can defend it.
The important question is not whether you added a voting button.
It is whether you thought about how people can abuse the voting system and what your platform does about it.
T4: Stretch
T4 turns the platform into something closer to infrastructure.
The requirements include:
- REST API
- Webhooks
- API access for UI actions
- Certificate generation
- Record generation
- Signed and publicly verifiable judge participation records
- Embeddable gallery widget
- Bulk import and export
T4 is optional.
Do not sacrifice a working T2 just to claim T4.
The organizers are very clear about this:
A clean, correct T2 is better than a broken T4.
What Counts as Done?
This is probably the most important requirement in the entire hackathon.
Your project needs to run locally.
The expected experience is simply:
docker compose up
The application should start with seeded fixture data.
No cloud account.
No hosted database.
No external authentication provider.
No external API.
No signup just to get the application running.
The organizers should be able to run your project with the network turned off.
That requirement exists for a reason.
The winner is supposed to be adoptable.
A project that depends on five external services is not something an organizer can simply clone and run.
The acceptance suite will run against your application and produce a tier by tier pass report.
That report becomes the evidence for the tier you claim.
If you claim T3 but the acceptance suite only confirms T2, you get scored at T2.
Honest scope is explicitly preferred over inflated claims.
What You Submit
A serious submission should contain something like:
your-portal/
├── README.md
├── ARCHITECTURE.md
├── DATA-MODEL.md
├── JUDGING.md
├── docker-compose.yml
├── src/
├── tests/
├── acceptance-report.txt
├── LICENSE
└── .dogfood.toml
You will submit:
- A public GitHub repository
- An OSI-approved open source license
- A working portal
- One-command startup
- The acceptance report
- README documentation
- Architecture documentation
- Data model documentation
- Judging documentation
- A 5-minute demo video
The documentation is not an afterthought.
ARCHITECTURE.md should explain how your system fits together and why you made those decisions.
DATA-MODEL.md should explain your schema and how data moves in and out.
JUDGING.md should explain judge assignment, scoring, and normalization.
"We averaged the scores" is technically an answer.
It is also a pretty weak one.
How the Projects Are Judged
The final score uses four weighted criteria.
Tier Completion & Correctness: 40%
How far did you actually get?
The acceptance suite verifies the functionality rather than relying on what you claim in your README.
Getting fewer features working properly is better than getting more features half working.
Judging Integrity: 25%
This is the hardest part of the platform.
Judges will look at things like:
- Backend role isolation
- Judge assignment
- Score normalization
- Audit trails
- Vote abuse prevention
- Whether your judging approach is documented and defensible
Adoptability & Operability: 20%
Could Hackathon Raptors actually run this?
That means:
- One command to start
- Seeded data
- Clear documentation
- Local operation
- Import and export
- No hosted-service dependency
- A clean open source license
Code Quality & Innovation: 15%
Does the code look maintainable?
Is the schema sensible?
Are the APIs designed properly?
And did you make a technical decision that makes someone think:
"I would steal that."
Bonus Challenges
There are four optional bonuses.
Normalization Proof: +5
Implement cross-judge score normalization and demonstrate it using the provided fixture data.
Show the raw scores.
Show the normalized scores.
Show how the rankings changed.
Then explain the mathematics well enough that someone with a statistics background can understand and challenge it.
Pairwise Mode: +5
Instead of asking a judge to give a project an absolute score, show them two projects and ask which one is better.
Then use a Bradley-Terry style estimator to recover a global ranking.
This is based on an approach used by Gavel and is one of the more interesting technical directions in the brief.
It is also hard to get right.
Threat Model: +3
Write a proper threat model for voting and submission abuse.
Think about:
- Sybil votes
- Ballot stuffing
- Submission scraping
- Judge collusion
- Deadline manipulation
Be honest about what your system prevents and what it does not.
API First: +3
Make every action available through a documented API.
Publish an OpenAPI specification.
If you design the application around the API from the start, this is much easier than trying to bolt an API onto the finished product.
The 72-Hour Strategy
Trying to build everything is probably the fastest way to build something mediocre.
You have 72 hours.
The scoring strongly rewards correctness, so the sensible approach is:
T1 → solid T2 → one strong differentiator → bonuses → polish
Get authentication and authorization right.
Get the data model right.
Get submissions and deadlines right.
Then spend serious time on judging.
If the judging engine is genuinely good, you already have a strong submission.
If you have a team, split the work around system boundaries.
One person can focus on the core platform.
Another can own the judging engine.
Another can work on public voting and the API.
Another can handle infrastructure, testing, and documentation.
The exact division does not matter as much as making sure someone owns each major area.
For a solo participant, scope matters even more.
A very strong T1 and T2 is a realistic goal.
Trying to ship every T4 feature alone in 72 hours is probably not.
The Interesting Engineering Problems
At first glance, Dogfood looks like a CRUD application.
It isn't.
The CRUD part is the easy part.
The interesting engineering is elsewhere.
Authorization
Can your permission model survive a direct API request?
You need to reason about relationships between users, roles, events, tracks, assignments, projects, and ballots.
A frontend permission check is not enough.
Judge Assignment
Imagine 40 projects, 30 judges, and three reviews per project.
Now add constraints.
Judges can belong to specific tracks.
Some judges may have conflicts of interest.
Workloads should be balanced.
Every project needs enough independent reviews.
This becomes an actual assignment problem.
Score Normalization
Different judges use scoring systems differently.
One judge might give 4 and 5 to almost everything.
Another might treat a 4 as an exceptional score.
A simple average does not necessarily solve that problem.
Your normalization method needs to account for judge behavior while remaining understandable and defensible.
Voting Abuse
"One account, one vote" sounds good until someone creates hundreds of accounts.
Now you have to think about:
- Rate limits
- Duplicate behavior
- Suspicious voting patterns
- Audit logs
- Account behavior
- False positives
- Privacy
You do not need to solve every voting attack in existence.
You do need to show that you understand the problem.
Offline Operation
The platform needs to work without relying on someone else's infrastructure.
The ideal architecture is something an organizer can clone and run locally.
Not:
Frontend → Hosted Auth → Cloud Database → External API → Five SaaS Services
More like:
Docker Compose → Application → Local Database
Simple enough that another engineer can actually operate it.
AI Tools Are Expected
AI coding tools are allowed.
The brief explicitly mentions tools such as:
- Claude Code
- Cursor
- Aider
- GitHub Copilot
- Local models
- Other AI coding assistants
The organizers are not interested in policing whether you used AI.
They care about the result.
A generated CRUD application is not particularly impressive anymore.
A system with proper authorization, a defensible judging model, a sensible schema, reliable deployment, good tests, and documentation that the team can actually explain is much harder.
Use AI to move faster.
Just make sure you understand what you ship.
Important Dates
| Event | Date |
|---|---|
| Registration Opens | August 24, 2026 |
| Judging Panel Announced | September 4, 2026 |
| Team Formation | September 21, 2026 |
| Specification Published | September 24, 2026 |
| Hackathon Kickoff | September 25, 2026 at 18:00 UTC |
| Code Freeze | September 28, 2026 at 18:00 UTC |
| Judging Window | September 28 to October 8, 2026 |
| Winners Announced | October 9, 2026 |
The official event website and Discord should be treated as the source of truth for any future changes.
Prize Pool
Dogfood 2026 has a $2,500 total prize pool.
There are prizes for the top projects, along with a Best Judging Engine prize and the Write Up Quest.
But the most interesting part of the prize is what happens after the hackathon.
The winning project is intended to be forked, self-hosted, and used for Hackathon Raptors events.
The team keeps ownership of its repository.
There is no assignment, transfer, CLA, or exclusivity clause.
The organizers also intend to send improvements and hardening work back to the winning repository.
That makes this feel less like building a throwaway hackathon project and more like contributing to an actual open source product.
Who Should Join?
Dogfood is a good fit for:
- Full-stack developers
- Backend engineers
- API engineers
- DevOps engineers
- Security engineers
- Data and algorithms enthusiasts
- Frontend and UX developers
- Developers interested in open source
- Students who want to work on a serious engineering problem
If you like building systems where the boring details actually matter, there is a lot to dig into here.
Authentication.
Authorization.
Data modeling.
Assignment algorithms.
Statistics.
APIs.
Security.
Testing.
Deployment.
Documentation.
All inside 72 hours.
Why This Hackathon Is Different
Most hackathons ask:
What can you build in 72 hours?
Dogfood asks:
Can you build something another engineering team would actually be willing to operate?
That changes everything.
A flashy landing page will not fix broken judge isolation.
A beautiful dashboard will not fix bad normalization.
A huge feature list will not matter if docker compose up fails.
The strongest project will probably be the one that feels boring in the best possible way.
It works.
It is secure.
The data model makes sense.
The judging system is explainable.
The tests pass.
The documentation is clear.
Someone who did not build it can run it.
And when the organizers look at it, they can imagine using it for their next event.
Final Thoughts
Dogfood 2026 is not another "build whatever you want" hackathon.
There is one product.
There is one specification.
There is a 72-hour deadline.
And there is a very clear definition of done.
Build the core.
Make judging trustworthy.
Enforce permissions in the backend.
Think seriously about normalization.
Make the application work offline.
Document the decisions you made.
Then use whatever time remains to build something clever.
The strongest submission probably will not be the one with the most features.
It will be the one where a judge can clone the repository, run docker compose up, look at the seeded application, and think:
"We could actually run our next hackathon on this."
Join Dogfood 2026
🌐 Website: https://dogfoodhack.com/
💬 Discord: https://discord.gg/xfYPDZYqeh
🦖 Hackathon Raptors: https://raptors.dev/
📅 September 25 to 28, 2026
💰 $2,500 Prize Pool
💸 Free to Participate
Build the platform that will judge you.
Top comments (0)