I just came back from Garage48, a 48 hour hackathon organized by Aalto Entrepreneurship Society and Garage48 in Helsinki. I had a ton of fun, met some interesting new people and built something awesome!

Our team, WeHearVoices, built a dead-simple but slick feedback tool for websites and web apps. Go have a look and register if you want a simpler, cheaper tool for collecting feedback from your users. The admin UI is based on an inbox with starred items; the integration only requires that you add two lines to your page. We'll decide on the next steps based on the feedback we get - so let us know if you want this product and do register/write your email so we can get back to you.

Update (day after Garage48): Some performance benchmarks for the WeHearVoices backend after I spent some time optimizing it.

It was a great experience! I loved being able to wrap up and ship a product that I would want to use in just two hectic days; closing a couple of sites as customers of the product during the hackathon was the cherry on top.

The great thing about our team was that we all shared a vision for a product that got its value from being simple - that made it possible to just do two meetings during whole thing (initiation and refinement) and we worked really well together despite having different skills and responsibilities.

I learned a lot more about building stuff with Node.js; got exposure to Django and Ubuntu server (if you follow this blog you'll know that I started Node.js during Christmas and do my server stuff on Centos) and learned about the way in which other people do web product work. Thank you Jens, Jori and Jukka! And thank you Garage48 and AaltoES!

You can find the list of startups at the end of this post. And here are some random notes that I want to remember for the next hackathon:

For thinking about ideas:

  • Big-and-visionary vs. small-and-shipped. The bigger your idea, the less likely that you'll get it shipped. We went with the small-and-shipped, which I think was liked by many entrepreneurs, but projects are evaluated based on both their ambition and their ability to execute on that ambition. If you want to be judged favorably, the sweet spot is probably somewhere in between the two ends with emphasis on working on the business, not the tech. For me though - with my unlimited supply of projects to do - shipping is an epic win.
  • Size isn't just about scope, it is also about expectations. Think about the expectations you create, since those determine how people judge your outcome. I think Bookstrap got too much flak from the judges since they weren't convinced that it was possible to build good-enough accounting software over a hackathon.
  • Judging is probably based on the interests of the sponsors (e.g. promoting their platform) - know their tech and you'll be more eligible to win.
  • Unusual is interesting. Standing out from all the other products is likely to make you an audience favorite if you can execute (that's a big if). Montroller did a great job with this!

For future productivity as a developer:

  • Get your server set up in advance; target the big-3 if you can (Ruby, Python, PHP). While setting up a server is insignificant on a long-term project, it does eat some time which could be spent better. We had two servers bought but there was still some setup work which took a couple of hours. I'd like to have that done in advance next time.
  • Have an automated way of doing deployment which uses a DCVS as frontend. We had a deploy script which was based on Python, which was mostly fine. However, since two (out of four) on our team didn't know Python and didn't have it set up on our computers, we ended up having the Python devs use the script while others only used Mercurial. If we had hosted the repositories directly on the server, and just pushed data directly to it (rather than via BitBucket) then we could have probably saved some troubles. Ideally, a push should trigger a standardized set of deployment actions which would be maintained on the server rather than a client-side deployment script, since it reduces the amount of stuff that people need to learn. I'll have to think about that, since I've written quite a bit about deploying and repo hosting using Mercurial.
  • Learn both git and hg. Since it seems that Windows supports hg well but does OSX rather poorly, while git supports OSX well but isn't quite as smooth on Windows (both are awesome on Linux). Hence people tend to know one or the other; if you know the basics of both, it'll be easier to get started. It's also a good idea to keep the cheat sheets and recommended configurations for the chosen DCVS somewhere so that people who need to switch can have get their environment set up quickly (e.g. username settings, diff tools). I still need to play around more with branching, since I am the only coder on my current projects and haven't yet tried out the variations.
  • For high productivity, use a shared technology/shared language to connect dev tasks. I wished I had known more about Django, since we used it for the adminstrative user interface and I probably could have helped more. Everybody knows Javascript, CSS, HTML and database schemas, so those provide a useful way to share work done with others. If you don't have the time, at least learn the frontend stuff (e.g. templating) since that allows you to contribute more. We ended up specializing so that the backend was written in Node.js, the frontend via Django and the widget design using jQuery; it worked here but I wonder about the next hackathon.
  • Have people who can dedicate time to think about particular aspects of the product; even if in theory you can do frontend or marketing, it'll be hard to keep switching between roles. Our solution to this was not to worry about marketing at all during the 48hrs - but that wouldn't work for all projects and we realized later that we ought to at least have had an about-us page.
  • Worry about the iteration you are starting now, not the next one. It's a tech thing to start thinking too far ahead, since we don't usually do sprints (e.g. 48h excluding sleep time) but marathons (months+). We did this right in our team: there was very little time during wasted on thinking about pie-in-the-sky architectures.

Want to be popular at the next event as a developer?

  • Do real-time technology; everything social benefits from having someone who can do Comet well. I had a lot of possibilities thanks to this!
  • Learn mobile development. Location sensing and various alternative user interaction methods are pop. Doing cross-platform well in particular is impressive.
  • Release your boilerplate code as open source. I did this, though we didn't get use the code since we had different tech backgrounds.
  • More good tips here.


Smola: Mixu,

Really nice recap and thanks for the feedback!


Miki: Thanks for the post, very good to hear how you liked the event as a developer!

Ramine Darabiha: Great blog post.

Regarding Bookstrap, it was in my top 3. I think the guys have done an amazing job, and Timo has progressed a lot as a speaker.

Santeri: Nice blog post.

WeHearVoices was easily my favorite product to come out of Garage48, I hope you keep pushing it onwards!