Most first-time hackathon teams optimise for the wrong thing: the most impressive-sounding tech stack instead of the clearest possible demo of a real problem being solved.
Before the hackathon starts
- Pick a problem you or someone on your team has actually experienced, not one that sounds hackathon-friendly.
- Split roles before the clock starts — who owns backend, who owns frontend, who owns the pitch. Deciding this mid-hackathon costs hours.
- Scope down. The version you can finish and demo beats the version you can only describe.
During the build
Working software beats a polished slide deck of a broken feature, every time I've judged or competed. Build the ugly version that works before you make anything look good.
The pitch is a separate skill from the build
I learned this the hard way with STROT — a system that took two days to build, explained in two minutes, and lost because the pitch didn't land, not because the system was weak. Rehearse the pitch as its own deliverable, separately from finishing the code.
What judges actually reward
Can they explain your idea back to you after one pass? Does the demo work live? Did you make a visible, deliberate tradeoff? Those three questions predict a scoreboard better than framework choice ever does.