How to Win a Hackathon

Start with the rubric

Devpost judge Karen Bajza-Terlouw said she first checks whether a submission fulfills the requirements, and she was surprised how many teams miss that floor. That means requirements are not admin work. They are criterion zero.

Richard Moot, another Devpost judge, said standout teams clearly considered the judging criteria instead of forcing an unrelated idea into the contest. AngelHack says repeat winners read the rubric before the problem statement. Do that before naming the app.

Shrink until the demo fits

Jackie Luc's CalgaryHacks team won first place out of 23 teams and 200+ participants after scrapping an unclear IoT idea and narrowing into House Guard, a remote home monitoring demo with sensors, dashboard, and SMS alerts. The win came after theme clarification, role definition, and pitch-first scoping.

Devpost winner Ansh recommends treating the product as a prototype with 2 to 3 must-have features. If your pitch needs five user journeys, you are not building a stronger project. You are creating more ways to fail in front of judges.

Build the skeleton early

AngelHack says the team with a working skeleton by the first 25 percent of the event beats teams still designing schemas later. In a 48-hour event, that means the first usable path should exist while other teams are still debating architecture.

Devpost winner Victor recommends small boilerplates for basic technology functions before the event so setup does not eat the sprint. Boilerplate is not cheating if the rules allow public frameworks and prewritten generic code. It is how you save fresh energy for the hackathon-specific proof.

Make technical risk visible

A hard build needs a visible hard part. Training Rails won a hardware track by showing a fullstack dashboard, hardware, and ML model for real-time rail defect detection. Chris Ho's team even used a fake rail so judges could see the real-time demo without needing an actual railroad.

The Medusa Paystack plugin won by matching a real ecosystem gap: Paystack parity with Stripe plugin behavior, code coverage, and developer experience. That is a better technical story than saying the stack is advanced. Judges can score a solved gap.

Write the pitch before extra features

Jackie Luc's team started with the pitch and target audience, then built toward the story. The project did not need every smart-home feature. It needed the cabin owner story, the core monitoring path, and enough proof that the solution worked.

AngelHack recommends a single-page demo script with problem, before state, trigger, aha moment, and close. If a feature does not appear in that script, it is probably not part of the winning path.

Lock, rehearse, submit

AngelHack says repeat winners lock code four hours before submission and rehearse the live demo five times. That sounds conservative until the Wi-Fi drops, an API rate limit hits, or the model takes too long in the judging room.

Devpost's planning guide says submit early enough for eligibility review, and AngelHack says repeat winners submit at least 30 minutes early because the deadline is when problems show up. Winning is often boring at the end: no new features, just a cleaner proof path.

FAQ