/ hackathon

Tips for conducting a Hackathon

This was our first hackathon in a while, and our first hackathon in the US. We knew we were here to learn about onboarding developers on to HyperTrack and so we did. What we didn’t know is that we would also learn how to conduct a successful hackathon. In this post, we share our notes about what worked and what we could do better.

Get noticed

Large hackathons like this one (300+ participants) have multiple sponsors and challenges. We are all looking for attention. We need to make sure we stand out of the crowd.

Prize - Offering the highest prize certainly helped us get interest from 20+ teams (out of 65). It was a good idea not to split our budget into several smaller prizes like several others did. High figures get a lot more interest. This is how the lottery works. Our challenge got the most entries because of this.

There are things we could have done better.

Goodies - people love free stuff. Our t-shirts were gone in 15 minutes. We should have brought many more.

Signage - our logo was not visible enough from far away. Time is counted. The audience should be able to locate us easily to come and ask questions when needed.

The one branding thing we did right was to wear our own HyperTrack t-shirts. Seems obvious in retrospect but still worth adding to the checklist. Here's the tee worn by our awesome Ohm:


Help people get started quickly

First of all, people do not come to the hackathon for you or your tech. They might not have a need for your product nor might they be familiar with your industry. In other words, they have less context than your customers, leads or visitors.

We weren't prepared for sure. You know your stuff so you think it should be easy for anyone, right? We were actually completely underestimating what it takes to go from 0 to 1. Frequent questions we would get were: "what's the next step?", "how can I do this?" "what can I use this for?".

This is why you need to take extra efforts to get them started.


Next time, we will prepare a one-pager with important information such as:

  • What you can build with HyperTrack
  • A Get started guide
  • Which APIs/visuals would be particularly useful in this context
  • A Get support guide
  • Last but not least, the winner selection criteria

Side note: things do not always work as expected on the day of the hack. WiFi was really bad for instance during the first few hours this year. So bad that contestants could not reach our website, docs or Slack support. We will be sure to print multiple copies of this document and bring it with us from now on.


Basic resources should be made available.

Sample app - teams do not have time to build apps from scratch in a hackathon. They prefer to get a running app and add features on top. Get your app up and running before the event.

Mock data - teams do not have time to generate sufficient real data for the demo. They will keep asking for work-arounds. Make it easy for teams to leverage useful data sets.

Support - make sure we have colleagues at HQ who can help with online support in real-time. We have found Slack to be very convenient for that.

These observations also helped us identify flaws in our onboarding flow for our regular users. We'll be integrating some of those lessons into our product.

Leverage the investment

Make sure to blog and tweet about your participants during the event. There is a chance they will retweet and spread the word.

The hackathon does not actually end when prizes are given out. Make sure to obtain the developers’ contact details so you can keep in touch. Getting additional feedback, hiring and partnering are all things that can start at the event and become valuable in the future.

Do more

Finally, and more importantly, do more hackathons. Our biggest takeaway was that hackathons offer a way to watch your target audience use your product. And to hear your users out loud. This is immensely powerful. Pains felt much more real. And actually hurt so much that we wanted to solve all problems right away.

Some issues had to do with lack of documentation, broken links and usability friction. Some were related to bugs. And interestingly the others were due to particular use cases we had not planned for. We might have taken much more time to identify those specific issues - and opportunities - should we have stayed behind our screens staring at metrics.

We decided that each developer in our team should experience this. We plan to start hosting hackathons on a regular basis. See you at one of them?