11 Hackathons, 11 Wins: What I Learned From Never Losing

During university, I attended 11 hackathons. I won all 11. People hear that and assume it's about being the strongest coder in the room. It rarely was. Most of what decided the outcome happened before a single line of code got written.

Scope is the real competition

The teams that lose almost always lose to their own ambition, not to the judges. They spend the first eight hours building a platform when they had time to build a feature. I learned to pick the smallest version of the idea that still demonstrates the "wow" moment, and to treat everything else as a stretch goal we'd only touch if we finished early.

Pick a demo path and protect it

Every hackathon I won, we decided the exact click-by-click demo flow within the first hour, then made sure that specific path never broke. Bugs in code nobody would see during judging were acceptable. Bugs in the demo path were not. We tested the demo flow itself more than any unit test.

The pitch is not an afterthought

A working prototype with a flat pitch loses to a rough prototype with a sharp pitch, consistently. Judges are usually evaluating a two-minute story: what's the problem, why does the solution matter, why did you build it this way. I started writing the pitch outline in parallel with the build, not after it.

Sleep is a strategic decision, not a sacrifice

Skipping sleep to add one more feature almost never pays off — a tired team makes worse decisions in the final hours than a rested team with less code. On the hackathons where we placed best, we set a hard cutoff the night before and stuck to it.

What I tell participants now

I mentor hackathon participants these days, and the advice barely changes: pick a small idea, protect the demo, write the pitch early, and get some sleep. It's not exciting advice, but it's the difference between a team that ships something judges remember and a team that ships fifty commits nobody sees.