5 Lessons From the Garage48 Helsinki Hackathon

Garage48 Helsinki, the largest hackathon in the Nordics, took place last week. It gathered 120 hackers from Finland, Estonia and Latvia under the same roof and challenged them to go from zero to demo in 48 hours. Sixteen startups were created during the weekend. Together with Osma Ahvelampi (CTO, Sulake) and Teemu Kurppa (co-founder, Jaiku), I was a mentor to those teams.

At Garage48, the goal is to produce a small startup, rather than just a really nice hack like you would at a traditional hackathon. There is a requisite for each team to have at least one developer (frontend or backend), a designer and a marketing person. At the end of the event, we had a demo day where the teams showcased what they built. From what I saw, many teams ran into the same problems, which caused them to miss their objectives. Here are some tips to get around those blocks and shine during demo day.

Sponsor

Aim Low

Startups are all about delivering a simple product to a niche that needs it. Garage48 is nothing different, but there’s only so much you can do in 48 hours. Aim low. Focus on technology you know. Some teams have problems compiling the tools they needed, so don’t plan too many features. It’s OK if it’s unfinished, as long as you can communicate its concept.

This doesn’t mean you should take the easy route and make a me-too idea. Build what’s needed for a good demo. Nobody cares if your payment processing really works, you just need to show that you’ve built something meaningful. One example was Montroller. The concept was simple: motion based remote control of a robot using your mobile. They built their prototype on the first night, so they had enough time to port to more mobile platforms, prepare a nice video and make their Lego robot look better.

Don’t Ignore Project Management

Most teams seem to ignore basic project management, apparently because they feel it is overkill. Instead, they prefer jumping into code and iterating. But without a list of deliverables, it is difficult to plan what will be built in 48 hours. You won’t have any time to pivot, so you need to make sure that your whole team understands and agrees on what needs to be built. Set a clear, detailed objective. People often forget the need to sleep (at least eight hours in two days), eat and prepare for the demo.

Another problem is that without planning, designers or marketers won’t have anything to do in the beginning. Also, make sure your team is a balanced team. Somebody needs to make a pretty website, GUI and write a blurb about your project. If you spend one hour planning ahead, your entire team can start working. Even then, you’ll probably end up with some team members having more free time than the others, so why not put them into action?

For example, Blow’Em was on its way to have a working game demo, but it was going to be a simple proof of concept. The designers and marketers had nothing to do, so they started working on a promo video, more characters and funny names, which made their whole demo more catchy.

Everyone in the Same Room

Most of the problems that teams run into seem to be related to bad communication. In some cases, coders will go into another room than the designers and the team leader. In practice, this means that whenever you run into a wall, no one can help you. It can be frustrating to explain to an art student why you can’t do 3D previews easily, but it’s better than producing all the assets in an unusable format.

Make sure everyone knows what is being worked on, and why. One problem with piecing a team of random people together is that you’re bound to have bad people in there. It’s important to identify them. Some people make snarky comments, shoot down ideas, or don’t listen; many teams waste time because of this. After all, you’re there to have fun, so it’s important you don’t offend one member of your team. While you can’t fire these people, you need somebody who can make the decisions and deliver results rather than to debate.

Go With “Good Enough”

A lot of people found it difficult to produce something just “good enough.” It’s difficult to pull the plug on a design or code instead of continuing to polishing it because you know it’s not as good as it could be. Doing this can slow down the progress of the entire team.

This can be especially problematic in group decisions. Many teams did not know where and how to look for domain names efficiently and thus spent a considerable amount of time trying to find a good name for their site. Focus on getting things done. If something unexpected happens, don’t just try to fix it for hours, talk to your team or the other teams. Maybe someone else solved it before. Drop extra features if you get stuck.

It’s All About the Demo

Last but not least, make a good demo. After all, it’s the only thing that others will see of your project. Make sure you test it before you ship. Videos are always difficult, because you need to make sure they will load, the sound will be on and the video can be shown in full screen on demo area’s second screen. Mobile demos are tricky, because cameras can’t easily capture what’s on a small screen from far, so you may want to consider using a web version, an iPad or slides.

Lead photo (members of LapLab, the winning team) by Ragnar Sass; bottom two photos by gunarsg

Discuss