My first hackathon: 24h of brainstorms, feeling ontop of the entreperneurship world, and panic attacks



In search of a completely new experiences, some go jumping out of planes, others buy a one way plane ticket, and I decided to register for my very first Hackathon. I wasn’t really sure what I was getting into other than what was described on the highly optimistic and deceivingly uninformative Vancouver Startup week Hackathon page that summarizes to: “100 people crammed in an office space. Come up with an idea that will take the world by storm, form teams, and create a viable product, probably a web app, all within 24 hours”. Well that sounds like a recipe for disaster and yet many successful businesses started this way.

To say that a hackathon is a high pressure social experiment is a serious understatement.

So I payed the registration fee, made a quick list of my applicable skills, and realized I needed an experienced developer on my team if I was going to do get anything done other than a pretty landing page (a few teams sadly only got that far). Oh and a clever idea of course. I did what many people do these days when you are an adult and have no problem advertising your need for help: I went onto social media to find anyone interested in joining me on this adventure. Jackpot! An old friend had some complementary skills AND a decently innovative idea. I learned much later that you don’t need a revolutionary idea to pitch a viable business model, get people excited about your product, or even make money. In fact you don’t even need a novel idea, you can take an old one but do it much better. But I am sure you can find more experienced people than myself to tell you about that.

In preparation for the Hackathon, I read a few “10 things you need to know to win a Hackathon”, one of which was particularly useful and I encourage you to read. My friend and I met at the mix and mingle hour pre-hackathon and met some of the other participants, some with brilliant others with really silly ideas, and completed our team: a back-end dev (my friend), a designer (a friend of my friend), a front-end dev (complete stranger!), and a project manager who would assist in all other areas as needed (that’s me!).

The most surprising lesson was that the team, its dynamics, and individual members’ skill-set is far more important than the quality of the idea.

I have to admit, the whole experience was much less chaotic than I would have imagined. Little time was wasted on the idea development phase, breaks were used to recharge on caffeine, and there were only two panic attacks. The first was a classic “everything broke 10 minutes before the presentation!” scenario, and the other was the slightly more terrifying realization that “the presentation of the product to the judges is included in the whole 24h. That’s only 22 hours of hacking. They lied! We’ll never make it!”

The plan, the pitch and the hourly log of progress made.

Luckily, we were fantastically organized and had a harmonious team dynamic that kept us productive. I didn’t find many “how to hackathon” blogs that commended a box of colour markers, large drawing paper and tape as essential hacking tools, but I brought them anyways. Turns out they were super handy. As the project manager, I realized I had to keep individual team members on track and ensured everyone understood their current and next task without needing to interrupt another team member’s concentration. Having a very colourful and rough sketch of the app’s components, diagrams of our app flow, list of features, etc., insured that the designer never had to ask the developer what art had to be made for what app page.

if you pitch your idea using sexual innuendos, it will be received as a dating app. Oops.

When it came to presentation time, we made sure to stand out and later the judges congratulated us on the quality of our app demo. We did so by:
-having a 1 liner pitch: “We created an social app for the outdoors community to help spark spontaneous adventures into the wild.”
-grabbing the audience’s attention in the first 10 seconds and pulling off a few jokes along the way.
-organizing our three minute demo as opposed to rambling about the features of the app until we ran out of time and were cut out by the MC.
-created a visual map of our business plan and projected on the screen. There is nothing more disapointing than seeing a demo of a beautiful product without demonstrating how to monetize it.

All in all I lost a ton of sleep, went through a serious caffeine withdrawl in the following days, but I learned a ton. For one, if you pitch your idea using sexual innuendos, it will be received as a dating app. Oops. But the most surprising lesson was that the team, its dynamics, and individual members’ skill-set, are far more important than the quality of the idea. We didn’t win any of the top three prizes but we did get noticed by the journalist covering the event in this news article. Will our product ever make it out to the public? It just might.

Check out to find out!




Peacetalk: Aid Accountability

I attended the first of this year’s peace talks organized by Peace Geeks. I recently started volunteering for the human rights NGO and thought I would come meet the team. It was also an opportunity to hear from speakers experienced in different aspects of aid and aid accountability, a topic that I know very little about.


accountability burger
The aid burger: sometimes you can’t just throw money at things.

Between the numerous stories of successful aid missions, those that created more damage than anything, and some where the finances were a bit wonky, two ideas stood out. First, I was intrigued to hear about Engineers Without Borders’ culture of admitting failure through the publication of a yearly failure report by the first speaker Emma Houiellebecq. Learning from ones mistakes in order not to repeat them is a lesson our parents teach us from an early age that we perhaps forget to carry with us in adulthood.

The second thing I learned was from Nora Lester Murad who gave her perspective on the other side of the aid donor-receiver equation as an NGO worker in Palestine. She brought up the too often neglected fact that aid is helpful only if it is helpful in the eye of the receiver. With that in mind she argued that accountability is an opportunity for both donors and receivers to understand the intended and resulting impact of aid. Though this fact seems logical she stressed that it does not reflect the reality of international aid efforts. I particularly liked her talk and will be checking out Nora’s blog. I am looking forward to reading the story she uncovered about the supply of temporary housing using metal caravans to homeless Palestinians that went sour come the cold winter nights and then the heat of summer.

To illustrate what I took home from the talks, I drew the “aid burger”. Directing money and aid at a crisis is not useful, and often can be harmful, if there is no infrastructure to facilitate its use. Diligence in accountability can fix that.