Since I moved to San Francisco a year and a half ago I’ve participated in 10+ hackathons. Those teams have won a combined:
60k+ in Cash
33k in Investments
70k+ in Prizes (mostly API/server credits)
When I quit my job in corporate america and came to San Francisco to start my own company, I needed a way to support myself. My money was starting to run low and my startup hadn’t taken off yet.
On the weekends I started participating in a number of hackathons because I love to hack. Turns out I’m decently good at them and ended up winning a number of prizes, and in turn that has funded my startup journey!
I’ve put together a process I follow that makes it more likely for my team and I to pull out a win. I’d like to share those tactics with you all and gain some feedback!
1. Understand what the judges are looking for
The first step to doing well in a hackathon is knowing what the judges are looking for.
Hackathons tend to have have main prizes, partner prizes, or many other various ways to win. Determining which prizes you aim to go after and what the judges are using as criteria will help you focus on executing.
If possible, you should try and talk to the judges for each prize you want to win, before the event if allowed or once you arrive, and figure out what they are using as their judging criteria. If it’s a startup offering the prize, email the founders. If it’s a bigger company it may be their developer evangelist. Reach out!
I learned this tactic from participating in the LAUNCH Hackathon Fall 2013 hosted by Jason Calacanis. We didn’t research well at all. The grand prize was a 100k investment split amongst the top 3–5 teams. We built an awesome project where a teddy bear could read a book to children and ask them questions along the way. The judges were looking for an investible business. Toys are a hits based industry and they couldn’t see it as a reliable venture investment.
We came away with $150 gift card and an awesome demo. Not terrible but not what we wanted.
Learning from my past experiences, I participated in the LAUNCH Hackathon Spring 2014. I specifically built my hack around a market and story that could be a venture investable startup. We ended up taking first place and received $33k in funding plus $30k in server credits to build out our business.
2. Start with the pitch, not the hack
One of the key rules of most hackathons is all of the coding has to be done at the hackathon. Oftentimes though you can do a lot of pre-work days or weeks in advance. Talking to your target audience, building your pitch, creating wireframes, and finding APIs. This will help you focus on mostly coding during the active hours of the hackathon.
My first hackathon in SF I built an app called InstaGift. It was an iOS app where you could get gifts overnight or same day delivered. It was for those moments when you forgot to get a gift for that special someone. I told a compelling story of how I forgot to order a gift for my (at the time imaginary) girlfriend and crafted a pitch around how InstaGift would have saved my day.
For this hackathon I didn’t come up with this problem until I was at the event, but the process still applies. Once I identified the problem, I determined who my target audience was. In this case my target audience were eCommerce executives (the judges) as well as validating it against other consumers.
I first ran the problem past both consumers as well as the eCommerce execs before I built it out. It rang well with both parties so I went ahead with the hack.
I ended up walking out with $5k for an app I built in 4 hours.
3. Build only what you are going to demo (at first)
Starting with the pitch helps you hone in on what you’re going to build and for who much faster, but it has a great secondary purpose. During the hackathon it’s easy to drift into building features that you’re never going to show. Login pages, auth systems, settings pages, fiddling with a corner case in your logic, the list goes on. If you are going to build those at least use something simple like Auth0 or Parse.
In starting with the pitch, I make sure to figure out exactly what feature set I’m actually going to be demoing. I then start building out only those exact features. It helps you focus on getting your core features down pat and away from features that can easily distract from your main goal.
If you do finish up building exactly what you’re going to show off, then you should absolutely go through, add some side features you skipped, clean up the UI, etc.
This can also be a great time to figure if you can build in any side features that leverage APIs or other requirements from sponsors and qualify you for their prizes as well!
Other random tidbits
Use the latest technologies available. I’ve built some great hacks, but lost to someone who built a unique implementation of keyboard. It had only been a few weeks since the iOS keyboard had been released and no one else built a product using that. It was very impressive.
Meet new people at hackathons, listen to their ideas (and distill them down to the core problems), and talk to judges and the sponsors. You never know if the person sitting next to you has a killer idea.
This is not a guaranteed to win methodology, but it is a proven track of how to think about approaching hackathons that has worked to help me support and fund my startup dreams in SF. I’ve executed this flawlessly in certain hackathons and won, but in other hackathons competing teams have used technology or a good story in a way that I had never thought of and they ended up building something better.
With all this being said hackathons aren’t just about winning money and prizes, that’s just one of the many great perks you get from participating in them. They are also an amazing way to meet new friends, build awesome projects, try out new technologies, and show them off on a stage to tens, hundreds, or even thousands of people.
(The article originally appeared on Medium as written by Brian Clark, co-founder of LinkTexting)