This past weekend, I attended the Startup Weekend event in Hsinchu, Taiwan. It was a great event, well-organized and a lot of fun. The premise of Startup Weekend is simple: On the Friday night, anyone can pitch their idea in 60 seconds. The participants then vote on their favorite ideas, of which 10 are chosen, and everyone then divides themselves into groups for these ideas. Then you have the Saturday and Sunday to create a first-iteration business: Determine the Idea and Target Market, do Surveys for validation, Design, Build, get feedback, iterate, and try and have a working business by the Sunday evening, where you have 5 minutes to pitch your achievements to a panel of judges.

My team was named TakeMyRoute, a tool to help you plan your travels or daytrips, share it with friends, and have others gain advantage from your research and give their own experiences while traveling the route. On Friday night we only had a basic idea of what the site needs to do, but by Saturday afternoon we had determined a marketing strategy and monetization strategy, done surveys, designed the pages for a Version 1.0, and started coding. My responsibility was to design and code the front-end of the site within 24 hours. Tall task, but by Sunday afternoon we had a live site up and running, and ended up getting 2nd place in the competition.

Here are some lessons I took from the experience that I hope can be useful to future participants of Startup Weekends across the globe, specifically those who are responsible for building the prototype.

Lesson 1: It’s a demo, not Version 1.0

The judges don’t look at your code, but they definitely like seeing a working demo. In fact, the teams that placed first, second and third all had basic demos of the concept up and running, and either demoed it live, or showed a video of it in use. So it’s clearly important to really have code working, and not just some designs that show the idea.

However, you only have 24 hours. In all probability, what you build in that 24 hours will have to be rewritten if you choose to go on with the project after Startup Weekend, no matter what you do. So dont’ worry about making the code understandable. Don’t worry about maintainability. Don’t worry about standards compliance. Don’t worry about efficiency. Don’t worry about browser bugs. If it works in just one browser, fine, you’ll just show that one browser. As long as one browser understands what you wrote and displays it correctly, you’re fine. Realizing this early on can save a lot of time. Our demo, for example, was just three files, each with around 500 lines of code, javascript, css and html all mixed together. But it works fine, and illustrates the concept well.

Lesson 2: Design is just as important as code, if not more

Make sure you have good (really good) designs for the prototype, and if you have time, add some nice visual effects to the demo. It gives the illusion of a well-rounded, working project. In the end, that’s what people are going to fixate on, and they’ll be quite forgiving if one part of the code is a bit buggy or not implemented yet. You can even make sure they just don’t see those parts, but are impressed by the quality and attractiveness of the designs that are already built into your product.

Lesson 3: Use API’s and existing code where possible

This is mostly about saving lots of time. Before you start implementing something, first google if there exists an API or plugin that does exactly what you want. If there does, it can save you hours (or days) of development. We used Panaramio’s API for images, Google Places for populating the map with suggestions, and of course Google Maps for the actual map and Directions for the route planning. This gave us a working, extremely impressive prototype in a matter of hours. Another thing that helps is to use some code snippets available online, or even better, some of your own that you wrote for other projects. It saves you time thinking about how to implement something if you can just copy-paste.

Lesson 4: Delegate

You have all the skills to build the whole project? Great! But you can’t. Choose the part you’re the best at or that’s the most important to finish for the Demo (for me, that’s front-end), and give other parts to team-members who are even just partly skilled in that area. You can’t do it all yourself. And even if your team-mate is not an expert, he has 24 hours to figure things out as necessary. He’ll still achieve more than you would have, since you’ll have no time at all to spend on that.

As for anything you come across that you realize you’ll now need to spend time on, but someone else could have done it (maybe changing an image from .jpg to .png, for example), delegate. Ask someone to do it and send it to you, while you carry on coding.

Lesson 5: Good Lighting

This is more of a practical lesson that I personally learnt: Good lighting in the room you are working is crucial. We had some really strong lights in our room, and that (along with ample caffeine) caused us to not become tired so quickly, my eyes to not feel as tired as they usually do and able to achieve a great amount in just a day.

Lesson 6: Have fun, and share your progress constantly

Just got one basic feature working? Be glad about it, and tell your team to come have a look as you demo it. This boosts team spirit greatly, gives you some quick feedback on the direction you’re heading in, and makes sure everyone stays motivated. It’s always really encouraging to see your team members achieving things - it inspires you to also have something great to show off. By the end of Startup Weekend, our team spirit was really high, and I think that’s due in a large part to our focus and constant achievements, right from the beginning.

Conclusion

Overall, Startup Weekend was a great experience, and I’ll definitely recommend it to anyone. If you’re a web developer / designer / app developer, your presence will be greatly appreciated, you’ll learn a lot of new things, and meet a lot of cool people. And if you’re lucky, you might just ignite a business that ends up growing to global scale.