Our DOGFOOD 2026 Experience
What happens when a hackathon doesn't ask you to build a random application, but instead asks you to build the platform that will actually run and judge the hackathon?
That was DOGFOOD 2026, organized by Hackathon Raptors.
The challenge was to build an open-source, self-hostable hackathon submission and judging platform within a 72-hour window. The platform had to handle the complete lifecycle of a hackathon, from registration and team formation through project submission, judging, and publishing the final results.
Our three-member team, Team Lumatrix, decided to take on the challenge.
It was also our first hackathon, which made the whole experience a pretty interesting learning curve. I had some theoretical and basic practical experience with several parts of the stack, but putting everything together into one working application was a different problem entirely.
The Challenge
DOGFOOD was much more than a frontend challenge.
The specification required a complete working portal with authentication, multiple user roles, event and team management, project submissions, judging workflows, and a public gallery.
Higher tiers introduced additional features such as APIs, certificates, and other extensions, but one of the most important constraints was that the platform had to be self-hostable.
It needed to work locally without depending on hosted databases, external APIs, cloud accounts, or network connectivity.
The submission also required documentation, tests, an acceptance report, and a five-minute demonstration showing a complete event lifecycle.
One principle became especially important as the deadline approached:
A smaller system that works is better than a larger system that doesn't.
That ended up influencing quite a few of our decisions.
Our Architecture
We focused first on getting the core workflow working and built the application around a relatively simple stack:
- FastAPI + Uvicorn for the backend
- SQLAlchemy + SQLite for database management
- Jinja2 + Python for server-side rendering and application logic
We chose a server-rendered frontend rather than introducing a separate frontend framework.
This kept the application relatively straightforward to run locally and avoided adding unnecessary external dependencies.
The backend handled authentication, database operations, and application workflows, while Jinja2 templates handled the user-facing pages.
For a 72-hour project, keeping the number of moving parts under control was useful.
The Integration Reality Check
One of the biggest lessons from the project was that knowing individual technologies is very different from making them work together.
Knowing how FastAPI or SQLAlchemy works doesn't automatically tell you how model definitions, database schemas, routes, templates, authentication, and seeded data will interact once they're all part of the same application.
During development, we ran into several situations where the application itself was running, but different parts of the system disagreed about the underlying data.
For example, database schema changes resulted in errors involving missing columns such as:
users.created_at
events.start_at
These weren't particularly complicated bugs, but they highlighted an important point:
Changing the application model does not automatically change an existing database.
Database state is part of the application too.
Authentication exposed a similar gap between theory and implementation. Registration, login, logout, and role-specific access all had to work together rather than being treated as separate pages.
That pushed us to think less about individual files and more about the application as one interconnected system.
The Judging Problem
The judging system was one of the more interesting parts of the project because DOGFOOD wasn't simply asking us to implement an "average the scores" system.
The specification placed a strong emphasis on judging integrity, including:
- Judge assignment
- Role isolation
- Score normalization
- Auditability
Our implementation used a weighted scoring matrix to evaluate projects across areas such as technical complexity, innovation, and presentation.
We also implemented an isolation protocol so that judges could only evaluate teams they were explicitly assigned to.
For score normalization, we implemented a backend z-score normalization process to account for differences between harsher and more lenient judges before generating the final leaderboard.
This was a good example of how a feature that initially sounds simple can become more involved once fairness and edge cases enter the picture.
Prioritization: What We Cut
A 72-hour deadline makes prioritization unavoidable.
We originally had a larger idea of what the finished platform could contain, but we eventually focused on getting the core event lifecycle into a usable state.
Our general rule became:
A working feature is better than three half-finished features.
Two planned features that didn't make the final version were a real-time WebSocket chat system and a dynamic Kanban board.
Real-Time WebSocket Chat
We initially considered an integrated chat system for communication between mentors and teams.
However, managing WebSocket connections and state while keeping the self-hosted SQLite setup simple would have introduced additional complexity and risked taking attention away from the core submission workflow.
We decided that it wasn't worth compromising the stability of the main platform for an optional feature.
Dynamic Kanban Board
We also considered adding a drag-and-drop task tracker for teams.
Instead, we used that frontend development time to focus on the participant and judge dashboards and make the core workflows cleaner.
It wasn't as flashy, but it was more useful for the actual requirements of the project.
This ended up fitting well with the overall philosophy of the challenge: getting the important parts right mattered more than trying to implement everything.
Working With AI
AI coding assistants were allowed during the hackathon, and we used them as part of our development process.
The interesting part was that generating code wasn't necessarily the hardest part.
The harder part was understanding the generated code, integrating it with the existing application, testing it, and fixing it when its assumptions didn't match our actual architecture.
AI can reduce the amount of repetitive coding significantly, but it doesn't remove the need to understand what the application is doing.
A function can look perfectly reasonable and still be incompatible with the current database schema, authentication flow, or surrounding code.
For us, AI was most useful as a development tool rather than a replacement for understanding the project.
What We Would Change
If we had another 24 hours, there are several areas we would revisit.
First, we would spend more time on UI/UX polish and responsive layout testing, particularly for participants accessing the platform from mobile devices.
Second, we would improve the database migration strategy by introducing Alembic. During development, manually resetting databases and dealing with schema changes became a noticeable bottleneck.
Third, we would add more automated tests around role-based access control (RBAC) to better cover authentication and authorization edge cases.
The biggest architectural change we'd consider would be separating the frontend from the backend entirely.
Instead of server-rendered Jinja2 templates, a dedicated Next.js + TypeScript frontend could provide a more dynamic user experience while allowing the FastAPI backend to focus primarily on the API and data layer.
That would also introduce additional complexity, so it would be a decision we'd make based on the project's requirements rather than simply adding another framework for the sake of it.
What We Learned
DOGFOOD was our first hackathon, and it was one of the first times we had to take a relatively large software specification and turn it into a working system under a hard deadline.
The biggest lesson wasn't a particular FastAPI feature or SQLAlchemy technique.
It was understanding how the different parts of a software project depend on one another.
Before the hackathon, it was easy to think about the backend, database, frontend, authentication, and documentation as separate components.
During the project, it became much clearer that they are tightly connected.
Changing a database model can affect a route.
Changing a route can affect a template.
Changing authentication can affect what an entire class of users can access.
Changing the judging system can affect the integrity of the final results.
And when all of that is happening under a 72-hour deadline, small changes can sometimes have consequences in places you weren't expecting.
Final Thoughts
We didn't build everything we originally imagined.
We did, however, finish with a functioning hackathon platform that we could run, demonstrate, inspect, and explain.
More importantly, we came out of the project with a much better understanding of the difference between knowing a technology and actually building something with it.
That difference ended up being one of the most valuable parts of DOGFOOD 2026.
You can find the project here:
GitHub: https://github.com/AKBh6/dogfood-hackathon-team-lumatrix
Thanks to Hackathon Raptors for putting together a challenge that made us build the infrastructure behind the competition itself.
Top comments (0)