The Top Ten Mistakes Of Running Hackathons

Editor's Note: Earlier this month, ProgrammableWeb spotted a Facebook post that took the producers of a specific hackathon to task over how the event was organized. We asked the author of that post, Brandon Wirtz, if he would be interested in writing something more prescriptive for ProgrammableWeb's audience. The idea? How can all hackathon organizers learn from the mistakes of their peers. This is particularly relevant for ProgrammableWeb since we are planning to run some multi-vendor hackathons in 2014.

Wirtz is CTO of; a company that provides APIs for natural language processing, summarization and search. Here was his reply:

In the past month I have both sponsored and attended hackathons. Looking back at those events it was apparent that there are at least 10 things you have to know when being an API sponsor at a hackathon.

1. Don’t leave your booth unmanned. Much of the hacking happens at 3 am. Nothing will lose you a soon to be loyal evangelist of your API faster than not being there to support them when they need it. A user waiting 6 hours to find out that the issue is a small error in your documentation will sour them against you.

2. Don’t sponsor if you haven’t tested your API’s thoroughly. For one of the hacks we were putting together, you had to call one API to get a list of products, and then hit a different endpoint for the product details.  The first API didn’t return IDs that were in the second endpoint because the second endpoint was a late addition. This API provider openly said their goal for the event was to test the APIs. Many of the hackers at hackathons make a living competing. One of our team mates was such an individual. The idea that he was betting this month’s rent on being able to build something that would win in some category made him unhappy to be a beta tester.

3. Don’t sponsor an event where you don’t get to pick someone to be in the finals. You are paying to be there. Your money is the prize money. Make sure you are going to get your API and all its coolness up on the stage so that everyone can see what it can do. Let the judges be harsh if they must, but make sure you can get at least one good example of your tech in front of all the attendees.

4. Don’t sponsor an event that doesn’t encourage the judges to favor sponsor APIs. I saw an awesome hack using an API that allowed developers to do all sorts of interesting things based on proximity to various wireless signals. The Judge at their table left them feedback that “there is no use case for this project” which was not the case. As I sat among the crowd of hackers who were reading and sharing emailed feedback, I seriously thought there might be a lynch mob forming. Not only was this a great hack for the API, it was just plain a great hack. It essentially made everything that had a wireless signal a near field communication device. A hack that would jumpstart a market which has been struggling to get adoption because no one has enough things with RFID or NFCs to really get user adoption would suddenly have lots of things to interact with. Every hacker in the crowd got it. But a bad judge combined with no knowledge of which API’s the judges were supposed to be looking for resulted in the team getting a two out of ten when the crowd would have given them an eight at minimum and many would have given it a solid 10.

5. Don’t sponsor a “feature” of the event that doesn’t work. The company sponsoring the broken WiFi that the teams depended on for Internet wasn’t winning points for having a WEP password of “Thank You *sponsor name*”. In fact the lack of reliability made for some funny jokes:

“What’s in your wallet?”
“Nothing I’m spending all my money on data overages so I can get some Internet in this place”
“Are you building a Financial App?”
“Yep, it is a micropayment system so you can divvy up infrastructure costs amongst your team mates at hackathons”

But this isn’t limited to infrastructure. The sponsored “breakfast” of soggy burritos filled with raw potatoes and strips of fat labeled bacon were not winning that sponsor any favors either. Whereas the sponsor who provided some very tasty Dutch Waffles won over quite a few hackers."

6. Don’t give away consulting, lunches, or advice as a prize. Sure the cost of being a sponsor was high. But you need to budget for a prize as well. Lunch is not a prize. No matter how smart you think you are, or your dev team is, you are being patronizing if you think that lunch with you is worth the $1000 the other API Sponsor is giving away. Believe it or not some participants at hackathons have done really interesting things, made millions, and aren’t just starving coders who will hang on your every word.  There are of course exceptions. If you are giving away lunch with the CEO of a billion-dollar-per-year company, lunch might be an OK prize. But short of that, stick to things that are a bit more tangible.

7. Don’t expect hackers to come up to you. Instead go out to them. Getting out into the crowd is the best way to get hackers to use your API. Ask what they are doing and engage with them about ways they could use your API. Don’t pressure. Just hint at things that might be interesting. This doesn’t mean you should convince the guys making something with toasters that it should also be a fashion app. It means taking the things that are a good fit and giving them a bit of a nudge.

8. Don’t sponsor an event that doesn’t have some press and bloggers in attendance. If you do great things and no one is around for it, does it really count? Many hackathons brag that they don’t have any bystander passes. You don’t want to sponsor these. You want people to talk about what was built with your stuff. If the event doesn’t have a good amount of press, it won’t matter if a group uses your API to solve world peace. This is also something you don’t want to leave to chance. Bring your own bloggers. Encourage press you have relationships with to attend. Make videos and promote them in your own social channels.

9. Don’t be afraid to get your hands dirty. Lend a hand. Helping a team with a code snippet, or “brogramming” with them to get them through a hard spot is great for you, and for the team. You will learn how your documentation should be improved and what pain points there are for those using your APIs.

10. Don’t be discouraged by out of the box thinking. The best hacks are the ones you never dreamed were possible. If your shopping API gets mashed up with a hardware hack for a talking bear, embrace it. Your car API gets mashed up with shopping, embrace that too. The idea is to have developers find cool applications. So embrace the weird and unexpected.

What about you? Whether you're an API provider or a developer, how do you think hackathons can be improved? Feel free to comment below.

Be sure to read the next Events article: How to use the 31Events API 1 of 3


Comments (1)