By Nate Aune
1. Set realistic expectations
There’s the temptation to go into a hackathon thinking that you’re going to build a 1.0 version of a product. The reality is that with only 24 hrs, you’ll be lucky to build something that actually works and is demoable. Make sure it’s something you can build in 24 hrs. Otherwise, you’ll spend the majority of the time postulating on all the different things you could build and trying to prioritize the features, and you’ll be left with a bunch of diagrams on the back of a napkin, but no actual thing that you can demo.
You need to think big, but start small. What is the simplest thing you can build that provides value? Err on the side of subtracting functionality rather than adding functionality. In lean startup terminology, this is called a minimum viable product (MVP).
2. Attract talent to your team
If you are a business guy and can’t write code, you’re going to need to convince a developer to join your team. Likewise, if you’re a developer but can’t design, you’re team is going to be much stronger if you can attract designer talent. Without the right people on your team, you’re going to be handicapped and have a hard time getting to a working prototype.
How do you attract talent to your team? Most hackathons provide an opportunity to pitch your idea before the hackathon starts. Write down a concise description of what you want to build, who it’s for, and why they would want to use it (what’s the problem that you’re trying to solve). And then practice your pitch so that it comes off naturally when you stand up to present it. State very clearly who you are looking for, and if you have a particular technology in mind, mention that too. If you’re planning to develop in Django, you just might attract other developers who want to code in Django too.
3. Get to know the vendors/sponsors
For our project Ourmy, we decided to use the unified APIs provided by Singly, rather than building all that code from scratch. Singly allowed us to authenticated users using their Facebook or Twitter accounts, and post status updates on behalf of those users to their Facebook and Twitter accounts. The Singly guys (Kristjan and Justin) were really helpful and we wouldn’t have been able to develop Ourmy as fast as we did without them by our side. We also took advantage of the Singly chat room to get questions answered by Singly engineers who weren’t even at the hackathon.
4. Do your homework
One thing that we didn’t do was to study the APIs before the hackathon. I highly recommend going through the examples and understanding how the various libraries you’re going to use are put together. That way you don’t spend precious time reading docs, and trying to figure out how to use a library or 3rd party API, but can focus 100% on building the functionality that is unique to your app. We spun our wheels trying out django-bitly, only to discover that it was broken, and so we reverted to using the Python library recommended by bit.ly.
The AngelHack rules state that you can’t write any code beforehand, but you can leverage existing open source libraries. Using existing code can drastically speed up your development time, but beware of code that is buggy or not well-documented. You could spend as much time debugging someone else’s code or scratching your head because of non-existent docs, than if you were to just build the functionality from scratch.
Where do you find trusted packages? Again, do your homework beforehand and select packages that are actively being developed (so you know they’ll work with current versions of your web or mobile framework), have good documentation and preferably you’ve already installed them and run the tests, so you know they work. For example, if you’re working in Python, look for an existing package at PyPi and DjangoPackages lets you compare similar Django packages. Crate.io is an alternative to PyPi that provides some additional information about the packages so you don’t have to go digging for it.
5. Use Github for version control
This seems like a no-brainer but I’m constantly amazed at how many developers are not familiar with DVCS such as Git. You can save yourself a lot of pain and frustration by setting up a repository on Github at the very start, and remembering to commit early and often. It’s much easier to roll back an atomic change, than trying to roll back a bug that was also committed with a bunch of new features.
Even better, use feature branches or have each person on the team work on their own branch. Rather than merging into master and potentially breaking the application for everyone else on the team, merge the master branch into your branch, and only after you’ve ensured that everything is working properly, merge it back into master.
We got a little bit lazy and on made the mistake of merging to master before testing things fully. Inevitably, this broke things badly an hour before we were supposed to submit our hack and we ended up having to make a new ‘predemo’ branch and cherry-pick commits into that branch to get the needed functionality for our demo. This was painful and could have been avoided had we been more careful with our git merging process.
6. Use a PaaS for deployment and hosting
This also seems like a no-brainer, but old habits die hard. Once you get used to doing something a certain way, even if evidence suggests there is an easier and faster way of doing it, we hold onto that which is familiar. Unless you’re using some obscure language that is not supported by the PaaS providers, you’ll be able to deploy faster and spend more time writing code and less time with tedious sysadmin tasks if you use a PaaS. Some that I like are Heroku, Dotcloud, OpenShift and Stackato, and if you’re a Django developer, read my post comparing various PaaS providers for Django deployment.
As with the vendor APIs, spend some time before the Hackathon to try out these PaaS providers to get familiar with the deployment process, and make sure that the PaaS supports all the features you need for the app you’re planning to build.
7. Take frequent breaks
When you’re under time pressure, and when the whole team is counting on you to build feature XYZ, it’s tempting to sit in one spot and plow through until you’re fingers are numb from all the typing. But this is a sure-fire way to burn out and even worse, hurt yourself with RSI. I always bring my Kinesis Ergonomic keyboard with me to hackathons, and my wrists thank me for it.
Remember to get up from the desk, stretch your shoulders and wrists, and go get a drink of water. Sometimes walking away from the code and coming back to it after taking a break makes all the difference in breaking through a tough problem.
8. Envision your perfect demo and work backwards
When I participated in Techstars Cloud, one of the hackstars, Alex Baldwin told me that the best way to prepare for demo day was to think about what you wanted to show in your demo, and then work backwards. In other words, build the functionality and UI screens that you need to show the audience what is unique about your app. A 24 hour hackathon is not the time to build a full-featured product, so focus on the parts that you want to show in the demo, and only work on those. If you decide to continue working on it, you can always come back and fill in the missing pieces.
It’s important to spend time making a decent video, and not wait until the last minute to do it. As with the APIs and PaaS, learn how to use a Screen recording software package before the Hackathon, so that you’re not wasting time trying to figure out how to get the audio drivers working to record the sound.
The official Angelhack how to make a hack video page recommends using Screencast-o-matic.com. I haven’t used this software before, so I can’t vouch for it, but if you have a Mac, I can’t recommend Screenflow enough. At $99, it’s not cheap but it’s the best. If you do Hackathons regularly, or you need to make a video of a new app that you’ve built and post to Hacker News, this software is worth it.
If you don’t want to spend $99 for Screenflow, you can use the built-in Quicktime player to make a screen recording. And if you to record the audio from your computer, visit this post.
9. Use an HTML/CSS framework
The AngelHack rules state that you can come to the Hackathon with pre-made wireframes or mockups, so you should definitely do this in advance, so you’re not spending valuable time doing this at the Hackathon. But what about the HTML/CSS? I’d highly recommend using Twitter Bootstrap or Zerb to build a nice-looking prototype without having to write hardly any CSS yourself.
If you’re worried that your Twitter Bootstrap site is going to look like every other bootstrap site, head over toBootswatch to get a free bootstrap theme, or Wrapbootstrap and buy a theme for a few bucks. The advantage of using something like Twitter Bootstrap is that you can assign someone in your team who is less technical but who has good design sense, to create the templates using Jetstrap, a completely web-based drag-n-drop tool for building Twitter Bootstrap templates.
The other advantage of using Twitter Bootstrap is that there are Omnigraffle Stencils available that you can use when you’re wireframing, which can translate directly into HTML/CSS without losing time in translation. In other words, there’s a one-to-one match between what is shown in the wireframe and the corresponding HTML/CSS element, so the wireframes will exactly match the HTML/CSS.
Like Screenflow, Omnigraffle is not cheap ($99) but it’s the best wireframing tool for Mac, so if you do a lot of wireframing/diagramming, it’s totally worth it. If you’re not ready to pay $99, you can get a two-week trial.
10. Have fun!
Remember that you’re at the Hackathon to have fun. Yes, it’s a competition but it’s also a place to experiment, meet interesting people, learn something new and build something from scratch. Don’t stress yourself out too much if you don’t accomplish what you set out to do, or if you don’t win. Just have a good time and put your best effort forward.