1) Make sure your presentation is flawless
2) Don't take on too big of a challenge.
We saw plenty of people that had great projects, but when they went up to present, they had the worst speaking skills I've ever seen, and failed to get their ideas across to the judges. Similarly, we saw plenty of people who took on too much in one weekend, and their presentation consisted of "Well, we wanted to finish X, but we ran out of time" or "This is cool, but doesn't work yet".
The projects we won with were never very complicated, but they were highly polished and you could instantly wrap your head around them.
Topical ideas are great. The judges can better identify with the problem that your hack solves, and it seems more relevant.
Hardware hacks tend to steal the show, e.g. a touch-enabled chalkboard, hardware "facebook", or a tweeting microwave. At three of the last four hackathons I've been to, a hardware hack has won. But be wary - at some hackathons they'll specifically tell the judges that the winning hacks must balance being awesome with being useful (specifically the facebook hackathon).
Fake it until you make it. This is a lesson I still need to take to heart. If your app doesn't look like it's going to work and you have an hour to go, hack together something that will give a good demo.
Actually, it's now "formerly from Twilio". He works at IFTTT now.
Furthermore ive seen people communicate with remote teams at Hackathon.
Both of these I see as sort of cheating, not unlike doping in sports, since idea of the Hackathon is to show what can be done in 10-20 hours of hacking.
- as the OP said, when presenting, start with the problem. But really insist on it so that it becomes painful for the judges. Show the problem you're trying to solve on existing sites/apps. Then show your solution on how you solved it. (See this post by Dave McClure for reinforcement of the idea: http://500hats.typepad.com/500blogs/2009/08/your-solution-is...)
- don't try to do too much: e.g. you don't need a web app + a mobile app to show you've solved the problem. "And we have a mobile version of it" doesn't help you in convincing the jury that there was a problem and that you solved it. Everyone knows that a website that solves a problem can exist in the form of a mobile app. You're wasting your time just mentioning it.
- don't discuss the technical problems you've had. For you it's interesting that you finally managed to get around that hurdle and it's tempting to quickly brag about it, but jurys don't care.
- while focusing on an API can work, I'd say to also try to incorporate some APIs if that makes sense and you have time. My hack was about showing movie schedules à la Hipmunk (a slow, uglier-than-it-was-then version is still up: http://flickmunk.com/), but I managed to find the time to add some Twilio pieces to it (I was familiar with the API already) and that was enough to win their prize too (a MacBook Air no less) while other hacks were fully focused on Twilio and didn't. E.g. if you need to store files of some kind, use Box or Dropbox if they're there. Don't push it too far though. Pick one or two that make sense. Your hack is not a NASCAR car.
- while your presentation should be as polished as possible, I was never convinced by people who made videos, flash animations or beautiful slides. I think some judges want to see a minimum viable product/PoC, not a PowerPoint.
- as far as polish go, I'm sure a nice design does help, but amongst the winners at Disrupt, it wasn't the most polished that won. (mine clearly wasn't) It was the ones who solved a problem and worked. Too much polish might make it look like you had been working on it for some time before. Nowadays, with Bootstrap, you get something decent-looking enough to get started. (though beware: everyone uses it too)
- finally, and that's important: be persistent. My old MacBook couldn't be connected to the projector at demo time so they told me I couldn't present. I was pissed! But I stayed around, asked for a second chance at the end if there was time, just for at least present. I almost gave up but I'm glad I didn't.
Of course, all this comes with "YMMV", or "your jury may vary". I think most judges look at demos and want to see something authentic, something that was really built during the hackathon and will excuse roughness around the edges. Some jurys can probably be swayed by a nice design and presentation.
I think Timothee hits most of the points very well. Nice job but I'd like to add a few things:
- To add to the "don't try to do too much" point, I'd say the vast majority of judges would like to see a few things done really well as opposed to a flock of things sort-of-done. When I mentor a group, I tell them to close their presentation with "Going forward, we'd like to also do A, B, and C. Any questions?"
- Avoid video if at all possible. Videos take 5-10s to switch into and another 5-10s to get out of. And that's assuming you have the audio set up properly. I saw a group recently spend ~10s switching, started playing the 30s video, had to stop it to adjust the audio, restarted it, and then ~10s to switch. It threw off the pace and ate a minute of their 5 minute presentation.
- Practice out loud as many times as possible. The demo will be smoother and just feel easier.
Yes. This has served me well. I got into a hackathon with the assumption that I'll be the only developer there. With that in mind, I focus on what I can accomplish in a weekend.
I plan for additional things, but I keep focus on what I need to do.
I also try to plan for additional people. For example, if I get another developer, what will they work on? A lot of it is back and forth, but having a plan at least gives you a place to start.
Planning is important, and lets you spend the weekend having fun instead of worrying about whether you will get done or how to manage a larger team.
I have tried searching and most events seem to be specifically for intra-company, or entrepreneurs vying for some piece of a pie.