A 7-Step Guide to Conquering Your Next Hackathon

June 13, 2014

Last weekend, my team and I won second place at the PayPal International BattleHack in Toronto. After the event, we were surprised by the number of audience members and fellow competitors who suggested that it’s not possible to build what we did in 24-hours.

I’ve decided to reveal some of our secrets to help you blow away the competition at your next hackathon.

Here’s the quick and dirty: there’s a fundamental difference between minimal viable product (MVP), productization, and a hack. By nature, developers focus on building functional prototypes. But a hackathon is the opposite of productization. At the pitch, you are selling a vision. So development efforts must align to support this. In other words, build the sizzle, not the steak.

This is an seven-step breakdown on how we spent our 24-hours.

1. Form a team.

I like to bring my own team AKA my twin brother Allan Shin. We’ve been coding together for over 20 years, and there’s just no substitute for the experience of a tight crew with specialization of skills.

If you need to form a team, a good ratio is two developers to one designer. If you are blessed with a designer who can code CSS you have a huge advantage. If your developer is strong, consider swapping a developer slot for another designer. Depending on your social skills, you’ll need pitch person. This is usually the industry expert or the idea person. For us, that’s our cofounder, Anisa Mirza. Don’t dismiss the importance of a powerful pitch and a well-rounded team. Articulating and storytelling is an art form.

2. Set up.

Your biggest opponent is noise and distractions. Find a quiet area unless you’re here to make new friends or learn something new. The closest available table just outside the hack pit with a power outlet is ideal.

Don’t wander off too far in case you miss important announcements throughout the day. If the event provides meals, setup close to the buffet table to ensure you’re fed first.

3. Concept and storyboard.

Once you know the theme of the event, decide on how to solve the problem and what technologies you want to use. Establish a solid game plan with time-boxed phases and stretch goals. This isn’t Agile, there are no sprints or iterations, just one. And remember, we’re not building up to a product. We’re building backwards from it. Prioritize because there’s only time to trim.

My company, Giveffect, builds crowdfunding solutions for nonprofits and we already use PayPal integration. So, it was obvious for my team to start building something along those lines. We set out to build Small Change.

Bonus tips:

If the event is sponsored by industry partners who promote their API’s, find a way to work that into your solution.

Build something targeted for kids or animals. Judges love that shit.

Don’t just build a webapp. That was cool 10 years ago. Today you’ll need something mobile. If you build something hardware or wearable, you’ll probably win.

4. Decide what to fake.

There’s a reason they call this a Hackathon. Remember that your “working” app is just an illusion. Your job is to be a good magician.

Most engineers are obsessed with functionality. Ditch that mindset. Don’t waste countless hours debugging code that has no net-effect on the judge’s decision. You can fake the engineering, but you can’t fake the design.

For your hack, plan the flow you’ll demo and the story you’ll tell. Then put together a strategy to enable this flow, while faking what you can. I would fake everything first using static data or screenshots, and work backwards to implement chunks as you have time.

5. Build.

You’ll most likely need a server, but you may not. Depending on your team and how fast you can do this, you can skip ahead two hours to start focusing on mobile. You can always fake the server with static content, even if your app depends on webviews.

If your team is stacked, go ahead and build the server. With all the frameworks out there and the magic of open source, you can have this ready in 15 minutes. Don’t stress on perfecting your models. Chances are you’ll only need one; fake the rest.

Typically the frontend is what takes the most amount of time. Go with open source, and copy a pretty CSS theme. Leave it to the pros.

Go with the obvious players: Bootstrap, jQuery, and FontAwesome. We allocated an hour to code the views and tweak CSS. Your speed depends heavily on your experience and the reference apps you have at your disposal. My brother and I work on a lot of projects together and our portfolio contains tons of code snippets that we can easily Frankenstein. What makes you an expert builder is familiarity with knowing exactly what you need and where to copy it from. Copy and paste is the basis of your hack.

6. Design.

If you want a shot at winning, you’ll have to “wow” the audience. For a non-technical panel, this means you need a polished UI.

Your designer should not be sketching or illustrating anything. Just like how you’re using open source, there’s no reason why you’re not using open design. There are tons of free PSD illustrations of buttons, menus, and backgrounds available. Start hacking up these UI kits. Or if you have a good designer, their portfolio should already include a bunch of these goodies. Here’s what we used as the basis of our hack:

We dedicated eight hours on Photoshop alone. It’s no wonder Small Change resembles this.

7. Troubleshoot.

So you’ve been making good progress but you’re running out of time fast. Essential features just aren’t working despite hour of debugging. What do you do now?

Be creative and exploit input devices. You’re a hacker, but so are magicians. Master the illusion.

For example, say you have a hack that detects a Salami Sandwich that triggers some activity on your mobile device to report which toppings taste best. But you just can’t get the code to work. Don’t let that stop you. Exploit the volume button, or the accelerometer as the trigger. In your demo, give it a quick tilt or secretly tap the trigger button once you bring the sandwich closeby. And continue with your story.

And there you have it. Follow these steps for your next hackathon and remember, people won’t question the stuff they expect to work. Instead they’ll be questioning how you managed to pull it off.

In the end, here’s what the judges had to say:

Judge: “Did you build all of this in 24-hours?”

Allan: “Absolutely.”

Judge: “Hashtag #Badass!”