How to actually win a hackathon
After five hackathons and a 2nd-place finish, the pattern is clear: it's a storytelling competition disguised as a coding one.
I've done five hackathons, with one 2nd-place finish to show for it. The losses taught me more than the win. Here's what I'd tell a first-timer.
Pick the demo, then build backwards
Judges see 40 projects in two hours. They remember the one with the 90-second demo that made them go "oh, that's clever." Decide what that moment is on Friday night, and build only what's needed to land it.
Scope is a weapon
The teams that lose are the ones that tried to build everything. The teams that win cut ruthlessly:
- One core flow, working end-to-end
- Real data, even if it's seeded
- No login screen — nobody is impressed by auth
Rehearse the pitch out loud
You will discover that the thing that's obvious in your head is incomprehensible out loud. Practise it three times. Time it. Cut a third.
The best technical project with a bad demo loses to a mediocre one with a great story. Every single time.
Sleep, a little
Your 4am code is your worst code, and you'll spend Saturday morning deleting it. Two hours of sleep beats two hours of bugs you'll have to debug while exhausted.
Most of my favourite side-projects — and one that became a real product — started as hackathon hacks. Treat the weekend as a forcing function, not a finish line.