I’ve recently won AppsForStudents, a hackaton where the goal was to create an application useful for students – in just one day! Together with my team member Bob van der Vleuten, I have won both the audience award and jury award.
Just a few months ago, I’ve also won the AppsForFlanders hackaton. There’s obviously no step-by-step process to win a hackaton, but I will share some tips.
Aim for impact
In the end, the goal is to create a useful application. A hackaton is not just a programming competition, it’s a lot more than that. When brainstorming about a concept for your application, aim for an application that could make a real impact on people’s lives.
At AppsForStudents, my team designed an application that saves students money and allows party organizers to attract more attendees. At AppsForFlanders, my team designed an application to help long-time unemployed people find a job. These things simply matter a lot more than saving a little bit of time or having fun by sharing pictures. At both hackatons, the jury mentioned they liked the winning application because it solves a relevant problem.
Work in iterations
Don’t start off coding something to hopefully end up with a great app at the end of the day. You have just one day and the chance this would work out is about 0%, as any software developer should know. After prototyping on paper, start with making a mockup design in Photoshop. This way, you make your ideas tangible and you can still alter the design without too much precious time lost. But there’s another advantage: you can now create an extremely simple “working” app that just contains the different Pohotoshop designs with clickable areas. In case everything goes wrong for the rest of the day, you at least have something you can show off at the end of the day.
After the Photoshopped mockups, start by developing high level functionality. Next, continue developing the functionality in iterations with increasing detail. Make sure to avoid having one perfectly working function and many other functions not working at all. A wizard-of-oz technique can also help a lot in quickly making it look like your application contains all sorts of functionality. While one team member is presenting, the other one can use a web app on his phone to trigger events.
At the hackatons I’ve been to, there always were a lot of people walking around and checking out the teams working. Competing teams might not give a lot of useful feedback, but the organizers and sponsors of the hackaton might do. Ask them to test your app for a few minutes, ask them what they think about the concept, etc. They can validate your assumptions, or prove them wrong. Or even better: they might come up with a solution for a problem or an additional feature your application should include.
I’ve heard it many times: half the work of a hackaton is done at the pitch at the end of the day. Therefore, you should prepare a clean, simple and short presentation and rehearse it. The jury has to be able to very quickly understand the application and how it makes an impact. A hackaton pitch is not a technical presentation for computer science professors, it’s a start-up pitch.
You’re application is very likely to contain a lot of bugs, so prepare for this by making a demo video. A live demo going all wrong is something you want to avoid!
The winning application at AppsForStudents
Wouldn’t it be nice if you could get reductions or free drinks when you go to a party with a large group of people? This was the winning concept my team developed for the AppsForStudents hackaton.
We implemented a prototype for a mobile application that allows people to browse parties in the near future and allows them to buy tickets for a group of people. The larger the group of people, the better the deals.
One of the challenges was developing a fail-safe payment system, so you can’t trick the system by saying you’re about to go to a party with 100 people and then show up with just 5. Additionally, the entrance of a party should not become a chaos when a large group is validating their ticket and everyone should be able to buy a ticket, even when a person doesn’t have a smartphone.
Using SMS messages, a failsafe method was designed. One person configures the deal (= number of people and selection of party), after which a unique code is generated and every member of the group has to send this code to the system using an SMS message. The deal is happening only when the exact right number of people has sent a message. When this is the case, they get a confirmation message (which is also used for the ticket cost) to show at the entrance.
Sure, there still are some problems (mostly business related, as SMS services take a large margin), but the basic idea is here. We had the opportunity to discuss the system with a person of one the largest student fraternities who immediately came up with a number of solutions, such as working with an identification badge instead of an SMS message to charge the ticket price. One thing’s for sure: there’s potential. The jury and audience clearly agreed, so we couldn’t be any happier! Okay, maybe we would’ve been happier with a free iPad or Android tablet than a Windows 8 tablet
One more thing
I was recently invited for the The Next Web Kings of Code Hack Battle, a two-day hackaton in Amsterdam. Should be fun, but I don’t promise I’ll win again as this one is obviously A LOT larger