Note: This article is part of the How to win a Hackathon series.
Don’t wait to deploy until the end
I’ve seen so many teams get burned by waiting until the last minute to get the server and deploy set up. I know working on the app is why you are in the hackathon and I know that’s the most exciting, but don’t take the risk that all your hard work will count for nothing because you failed to get it deployed. Getting the server set up and working should be the very first thing you do. Make sure you have deployed, through git, to the server and see a basic Rails home page deployed and running.
Use Google Analytics and Woopra
More than anything this is for curiosity, but you’ll be thankful you did it when the judging starts. Google Analytics is great for historic reports, but nothing beats Woopra for live tracking of your users. We watched every judge come in and look around our app. We could see which ones really spent the time reviewing or apps and which ones barely looked around.
Have a link from the site back to voting
We failed to do this the first time and I think it hurt us. Many visitors may find your site directly via a share from a friend, and they may not be aware that you need votes. Having a prominent link on the home page asking for their vote with a link to the hackathon page helps communicate your situation and will get you more votes. You could consider implementing the Hello bar to accomplish this quickly.
Create a blog off-site
When the hackathon ends you can’t make any further changes to your app. This includes communicating valuable information to your potential users. I’ve seen apps that had a major bug that was preventing everyone from trying it. Though there was a way around the bug, there was no way to communicate to the users how to do it.
If you set up an offsite blog (Tumblr for example) and link to that from your site, you can publish updates and news there during the judging time without having to make modifications to your app.
The same suggestion applies to having a Facebook page and Twitter account. If you link to those from your site, you can then use all of these options to continue communicating with the users and the judges after you hit that code freeze.
Follow up with immediate bug fixes
You won’t be able to fix any problems found after the code freeze until the judging and voting is over, but that doesn’t mean you can’t have the fixes ready to go.
We fixed everything as it came up, and the minute we were cleared to update we did.
This way if your app gets any press post-hackathon, the visitors will see a more improved and bug-free version.