What's the difference between a hackathon project that amazes the audience versus one that lands with a thud? For better or worse if you're looking to win a hackathon it takes more than just code to impress the audience.
Here's the list of winning attributes I've seen after spending much of 2014 assisting and judging teams at both college and professional hackathons.
I'll elaborate further on each of the above items and provide links to resources that'll help your team effectively handle each one.
For example, a messaging app that allows you to text to your friends over a cell phone data connection instead of through SMS would be silly because there are so many well-known apps for that already out there: WhatsApp, SnapChat, Facebook Messenger, etc.
However, the reverse of the SMS-data connection is brilliant: if you don't have a data connection but you do have SMS you can use SMS as a data connection instead. This is what the MHacks team that built the Cosmos Browser showed an amazed audience earlier this fall.
The idea doesn't have to be mind-blowingly original though. You can often take something that already exists, such as a public government web API and make it accessible to a group of people who previously had trouble accessing a resource. For example, Boston recently launched their v2 API for bus schedules. Instead of building a mobile app that only worked on iOS or Android, a team at PayPal BattleHack Boston combined the new API with Twilio's SMS API so anyone could text a phone number for the bus schedule. That opens up bus schedule access to feature phones in addition to iPhone and Android smartphones.
If you're looking to do something novel with Twilio, we just launched MMS on all US phone numbers a couple weeks ago. We've built a few hacks already including a digital coupon creator, meme generator, picture scavenger hunt and oh yes, even a drinking game. However, we have not barely begun to explore the limits of MMS so there's a whole lot of room here for amazing hackathon projects.
Estimating software development effort is notoriously difficult even on short time frames. Pare the scope of your idea back to what you believe your team can accomplish in 3-4 hours. If you start with an idea that takes 36 hours and you run over you could end up not finishing and even worse, not sleeping. Teams that don't sleep usually end up not pitching well because their brains are fried.
Small scope doesn't mean an unimpressive project. There's a huge shortcut here. If you take one thing away from this blog post: leverage open source libraries and web APIs.
Pretty much every winning team uses a combination of open source libraries and web APIs in their hacks because it's like adding hundreds of other developers to your team. Depending on your language of choice familiarized yourself with and use a project template.
For Python, check out the project templates for the Django and Flask frameworks. If you're new to the web development game, Full Stack Python explains each layer of the Python web stack and provides links to the best resources on the web for each topic.
For other langauges check out this handy hackathon starter project page on GitHub.
If you don't know what libraries exist for your programming language check out the awesome-lists which break down libraries by functional area.
For web APIs the usual suspects are Twilio for voice and text message (and now MMS) functionality. Sendgrid works well for email, GitHub offers up pretty much all their data through their API and Google's APIs work well for hooking into their services. As mentioned earlier, the list of government web APIs are all free APIs ready to be used in your hacks.
Remember: less is more. I've seen groups try to demo their web API, web app and Android and iOS mobile apps all together in under 2 minutes only to have the presentation feel rushed and disappointing. It's better for a group to come up with a single amazing solution with a tightly scripted demo than several apps that you will not have time to show.
Pitching requires practice. At PayPal BattleHack the teams have to do their presentations to hackathon organizers during the weekend before they get to participate in the final pitches. Do the same even if it's not required for your hackathon. Find another group or an engaged sponsor to give you constructive feedback on how to improve your pitch and demo.
I wrote a page on pitching resources for startups that's just as applicable to hackathon pitches as small companies.
View the demo and pitch as 60% of the work that goes into a hackathon if you want it to work well. And if you're just at the hackathon to have fun and learn instead of trying to win (which is how I would approach a hackathon), it's still a great experience to get up on stage and demo software to the crowd.
When I'm at a hackathon representing Twilio I'm there to help your team, regardless of whether you're using our API or not. I'll usually be in my red track jacket walking around or posted up in a visible location. If you can't find me tweet me @mattmakai to get the fastest response. You can also email me at makai@twilio.com. Happy coding!