Building a Hackathon Platform Without Knowing Docker First
A first-semester CSE student built The Lone Wolf hackathon platform for Dogfood 2026 using Docker Compose and SQLite.
Stock photo for illustration only, not from the actual event
- First-semester student built solo hackathon platform The Lone Wolf
- Architecture runs entirely on Docker Compose and SQLite
- Test fixture includes 40 teams, 30 judges, and 41 projects
- Backend strictly enforces all security and scoring rules
At the start of their first semester in computer science and engineering, the developer did not yet know what Docker was, yet they decided to build a self-hostable hackathon platform running on Docker as a solo submission for Dogfood 2026.
The most crucial architectural decision was keeping the entire platform local and self-contained. The application operated through Docker Compose, used SQLite for persistence, seeded its own fixture data, and avoided relying on hosted databases, external APIs, or cloud authentication. What initially felt like a specification constraint eventually became the foundation of a system that had to be reproducible from a clean start.
Building an application without external services to compensate for implementation flaws is an excellent practical approach for learning software engineering. It forces developers to understand container mechanics and database management at a lower level rather than relying on managed cloud abstractions.
Another major challenge was enforcing operational rules. For instance, deadline enforcement could not rely solely on hiding or disabling the submit button on the user interface, as users could bypass UI restrictions by calling endpoints directly. Consequently, the backend had to enforce deadlines and role isolation server-side across all user permissions.
Stock photo for illustration only, not from the actual event
The supplied test fixture was intentionally complex and included the following specifics:
- 40 participating teams
- 30 judges
- 41 projects
- 8 tracks
- 126 total scores
The fixture also presented awkward edge cases, such as unfinished review batches, a judge giving identical scores across projects, and two distinct projects named Dry Harbour belonging to the same team. Rather than silently cleaning up unusual data, the developer ensured the data model correctly permitted a single team to have multiple projects.
Scoring implementation also proved more intricate than expected due to score normalization across judges. Because judges utilized scoring ranges differently—with some using the full spectrum and others clustering scores tightly—the application had to account for real input data behavior rather than applying a naive mathematical formula.
Finally, community voting introduced hidden complexity. What initially sounded trivial required token-gated voting, randomized ballots, duplicate prevention, comments, rate limiting, an audit trail, and hidden results while voting remained active.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment