Anatomy of a good hack

Learnings from an app built in less than a day

I am a product manager at a startup who recently hosted a photo-related hackathon. We were lucky enough to have a great organising team for the event, which allowed most of us to hack on things. I wanted to share a few thoughts about what I think helped us make our hack successful. This is my first post on Medium.

Our team built Snapcat, an app that lets cats take their own photos. Yes, it sounds stupid. Yet, the BBC, Fast Company, Wired UK, and others wrote about us. We won an API prize. Everyone congratulated us after the demos session. Snapcat for Android was downloaded ten thousand times. Thousands of people have tried it on the web.

The press and the numbers don’t really matter because we all have real jobs and the project has tons of issues that we probably won’t take the time to fix, but we built and shipped something in less than 24 hours and it worked. That’s cool.

Here’s a little list of things we did during the event that could maybe help others make good hacks, regardless of their initial idea. Some parts are obvious, but it’s easy to forget when you start working on a new project.

• Agree on the basics: do it early. You don’t always know the people you are going to hack with. We were a team of 5. We did wireframes. Super basic wireframes. It took us 10 minutes and everyone agreed about what the app needed to do and in which order to get there. Make sure you sit down and talk so everyone knows what’s going on. It will save you time later on.
• Build in blocks: build an MVP that barely does anything, and get it to work first. It needs to work. Really. Think of other features as modules you could add if you have time, but wouldn’t break the whole concept if things went wrong. Aim for having something that (sort of) works within 12 hours. You probably won’t manage to do everything you had planned. You’ll probably fall asleep too.
• Sync with your team regularly: do it every hour if you can. Make sure you don’t forget the basic requirements of your hack. It should be easy to be aligned with your team if you agreed on things before starting.
• Show your hack to other hackers: people won’t steal it from you. “Ideas are cheap” and all that stuff. Showing early versions of your hack to other people helps you understand how the audience and the judges will perceive it during demos. It helps you find an angle for your pitch.
• Prepare a short pitch: when you have 2 minutes to present on stage, being able to explain clearly what your app does and why it’s cool in two or three sentences helps you win. It also gives your more time to demo your product. Ours was something like “Snapcat is an app that allows cats to take their own photos. It looks like a game in which cats have to catch something that moves on the screen, and a photo is taken every time they hit the screen with their paw. You can then choose the photo you like best, add filters and stickers, and share it to EyeEm, Facebook, and Twitter.”
• Don’t bother making a presentation: nobody cares. Demo is king. During our hackathon, presentations weren’t even allowed. Also, don’t try to replace a PowerPoint by an HTML presentation (yeah, a website that explains your project without showing it is the same).
• Practice your demo: demos are hard. You have 2 minutes. Nothing ever works properly. Even Apple and Google still struggle with live demos sometimes. Be prepared. Practice the flow you want to show. Log in in advance. Assume everything will fail and that you will have to restart in the middle of it. You should plan to have enough time for those things. We knew we could demo the app in less than 30 seconds. We ended up having enough time to demo Snapcat on Android and on the web.
• Ship it: this is the most important part. You have to ship your hack. From the very beginning, our goal was to have our site up and running and to publish the Android app before demos so we could tell people to go try it right away. Android is great for that because your app will can be live within a couple of hours. We knew we had to be done by 9am latest. We also knew we had a few extra hours to polish the web version once we had submitted the app to Play Store. This makes a huge difference when you compete with people that demo an app in an emulator or on localhost.

The awesome team behind Snapcat was Danielle Reid (capsule.fm) and 4 guys from EyeEm (Łukasz Wiśniewski, Victor Mark, Tobi Poel, and myself Matias Castello). We know the app is full of bugs. Sorry.

Feel free to share your experience or tips about hackathons or executing ideas fast in general.