Garage48s are hackathon events in Europe and Africa where teams have to take an idea to prototype in mere 48 hours. They are pretty addicting, I’ve personally participated 6 so far. With that many events I’ve learned a bit how to make maximum of the 48 hours as a developer, which I’d like to share with you. Even though the following tips are based on Garage48 events I’m sure they also apply for other similar hackathons like Startupbootcamp.

Before the event

Version control

Go through different version control systems like Git and Mercurial (Jokes will be on you if you choose to use SVN 🙂 ). Make sure you have them installed and have all the tools needed to for effective use (proper diff- and merge tool for example.). I for one like graphical user interfaces for both Git and Mercurial, thereby MacHG and GitHub for Mac are my friends.

Also go through a basic documentation, especially if you haven’t used one of them in some time. At last Garage48 in Tallinn I found myself knee deep in Git even though I use Mercurial daily.


Hosting and server configuration

Chances are, that you have to set up everything necessary to run the prototype on live server yourself. No matter what technology you prefer, go through the process of setting up everything on blank debian installation before the event. This is really important as it’s stupid to lose several of your precious 48 hours on googling Apache configurations.

Choosing the team

Think through your intentions for the event. Are you looking to actually go for a startup company (like Campalyst or Qminder did) or just a fun experience? If you are not planning to stick with the team after 48 hours, don’t go for business-ambitions ideas. Rather take something you really can deliver in 2 days. Chances are, you’ll have much more fun in the process.

During the event

You can switch teams

If you feel that the team or project you chose is really not right for you it’s better to change the team than just walk away disappointed. At first Riga event our team was merger of 2 similar ideas. On Saturday morning we got a message on Facebook from one developer and one designer (who were together..) saying they don’t actually like the idea and they are leaving (If you two are reading this, your shame shall be eternal!) We went on to win the event with Planify. Some other team is always happy to have another sprintf(“%s developer”,”Your favourite technology”).

If possible, take the easy way out

Make things as easy as possible for yourself. If you are building a simple LAMP application, you might be better off hosting your application on virtual server (GoDaddy/Hostgator for example) rather than an instance you have to configure (seriously, every minute spent on configuring platforms is a minute wasted, unless you really have to).

If you have to choose between platforms, go for simplicity over speed or features. Qminder wrote their first prototype in PHP and later ported it to their technology of choice Java. If you go on with the project, you will eventually scrap all the code written during the event anyway. The more features you can include in your prototype the better. You will probably only manage to implement only a fraction of what one would consider MVP, don’t make things harder for yourself.

Who writes the code chooses the platform

And that’s it. Unless project manager and marketer(s) join in and substantially contribute to the code base, you can completely ignore their demands on the technology of choice. If you and fellow developers like PHP your project will be written in PHP, not Ruby on Rails or Java. If you have Android competence, yet the original author of the idea wants iPhone application you will be delivering the Android application. Simple as that.

Their competence in another technology might be an advantage later on if you decide to turn your prototype into a startup, but at first, you have to deliver a prototype. That takes me to next point.

Garage48 is the best learning experience

If your team is competent in another platform, take it as a change to pick their brains. Swallow your ego and take a chance to experiment with a new technology. Even though you will be less productive, you will get more out of the event. Your teammates will be happy to help you out. There is no better way to learn a new language than being obligated to deliver a prototype using it in 48 hours!

Get at least 4 hours of sleep a night

I’ve gone through one event with 48 hours straight hacking and networking (read: a lot of rum). It wasn’t worth it. You’ll be much much more productive if you have had some sleep at night. For me, the absolute minimum is 4 hours. If the event is not in your hometown, take a hotel room. Sleeping on the floor at the venue is almost equivalent to no sleep.

Don’t leave deployment on live server to last minute

It can be irritating to find out that rails won’t compile on live server for one reason or another. It’s devastating if it happens 30 minutes before the final event. Something always goes wrong while publishing the app, be ready to make last minute changes on live server if necessary.

At very first Garage48, we actually got our 100% working prototype live only after we had demonstrated it! It didn’t matter because people probably didn’t even notice it and we actually won. Just be ready to put out the last-minute fires.

And most importantly have fun. Stress will get you nowhere.

Leave a Reply

Your email address will not be published. Required fields are marked *