I signed up for my first hackathon knowing almost nothing about what to expect. I came out knowing something about myself I hadn't known before: I work best under pressure, with a deadline that cannot move.
Scope Ruthlessly
The most common hackathon failure mode is over-engineering. Teams spend 30 hours building infrastructure and 2 hours on the product. The winning teams I've observed do the opposite — they identify the single feature that demonstrates the idea and build only that, with enough polish to feel real.
The Demo Is the Product
In a hackathon, you're not shipping software — you're shipping a narrative. The story of why this matters, who it's for, and why you're the team to build it matters more than your stack choice. A compelling demo with a broken backend beats a robust system with a boring pitch every time.
What I'd Do Differently
Sleep. Even 4 hours changes the quality of your decisions in the final stretch. And commit to a stack you know — hackathons are the worst time to learn a new framework. Execution under constraints requires fluency, not curiosity.