Winning PDX Startup Weekend

Success at a 54-hour hackathon, and how the experience translated (or didn't) to the real world.

Quinn Rohlf · 01 Jun 2013

Last month, the LivFly team was crowned the overall winner of Portland Startup Weekend Spring 2013, a hackathon-style event that challenges developers, designers, and business people to build and validate a startup over the course of a weekend. I was the main developer on our 6-man team, and we were able to put together an impressive demo in less than 24 hours time. The team’s accomplishments landed a first-place $10,000 prize package of consulting and legal help.

A week later, I quit the project.

The Weekend

The actual Startup Weekend event went by very quickly. The pitches happened on Friday night at 7pm, and I decided to join up with Chris, a guy pitching an app for connecting people who want workout partners for things like running or cycling. It was an idea that I was invested in because I’m a rock climber, and it’s pretty common for me to have to spend a lot of time trying to find a partner to go climbing with on the weekends through inefficient methods like Facebook or forum posts. Chris’s idea seemed like a great way to tackle some of the pain points of trying to find a climbing partner on the Internet. The two of us started recruiting other developers, designers, and business people, and soon we had a solid 6-person team.

At the end of the weekend, everything in the competition is judged based on three things: execution, customer validation, and business opportunity. With that in mind, we narrowed our focus to just connecting running partners, and got to work. The team talked until nearly midnight Friday night, knocking out a basic idea for what our MVP would look like and discussing possible revenue models. As a developer, I was most passionate about the execution side of things and chose to focus my efforts on organizing our three developers and building the best product we could with the short timespan we had.

An often-repeated mantra in startup land is “fail early, fail often”. After our dev team had spent 6 hours on Saturday morning building out our app’s UI using Ratchet, we decided to scrap everything we’d built and start over after realizing that Ratchet had some major bugs on Android. This was actually a high point of the weekend for me - I think it was really useful to have the experience of making a project management mistake (I was the one who had decided we should be using Ratchet), recognizing that mistake early, and cutting the team’s losses by switching to a new platform.

Meanwhile, the marketing/business side of the team was encountering their own difficulties. I was occupied with building the product so I can’t say what actually happened with them on Saturday, but I do know that they still hadn’t agreed on a revenue model or done any customer validation by 11pm on Saturday night. This is another takeaway that I had from startup weekend - the developers I worked with were very willing to consider alternate approaches to a problem, were good at picking a goal and accomplishing it quickly, and basically Got Things Done. However, I got a very different impression from most of the business people (“hustlers” in Startup Weekend terminology).

The hustlers on our team had very strong opinions about what revenue models were and were not acceptable, and each had their own idea of where they wanted the project to go beyond the weekend that kept filtering into discussions about what to do for the weekend itself. I distinctly remember one of my hustler teammates refusing to even consider the “paid app” revenue model despite having just seen a video of 4 random people we picked off the street saying “yes” when asked if they would pay for the app.

This was another useful learning experience, and I learned two important lessons from it:

  1. Having a co-founder or partner who is non-technical or a “business” person might not always be the best idea, and
  2. It is just as important for non-technical members of a project to share the same vision as it is for developers on the project to be writing compatible code.

In the end, we pulled it all together into a compelling presentation and demo application, winning the overall prize. As the weekend ended, things were looking very exciting for the team. Our idea had been validated by a panel of judges, we had money for consulting and legal fees, and we were all excited about the product.

The Aftermath

Fast-forward to today. I’m no longer on the team, no new code or marketing materials have been produced since the Startup Weekend, and LivFly is mostly back to being just an idea of Chris’s. What went wrong? I think that Startup Weekend forced us to take an ambitious idea (“connect people who want to do active things together”) and make it much less ambitious (“pair running partners”). It’s useful that we were able to focus on such a specific task for the weekend, but after the weekend the project should have bounced back to its original, ambitious goal of connecting all types of workout and exercise partners. Instead, we got stuck in a rut with an idea that was less exciting and less ambitious. The extremely abbreviated nature of Startup Weekend encourages people with ambitious ideas to aim low in order to be able to validate and prototype a startup idea in 48 hours. While this poses a great opportunity to learn very quickly, the ideas that make it out of Startup Weekend are hobbled by the need to adapt them to such a short timeframe.

To summarize my thoughts on Startup Weekend, I’d say that Startup Weekend is a great learning tool for people, and a terrible launchpad for ideas. Do I plan to do another Startup Weekend in the future? Absolutely. But I’ll do it for the educational value, and not because I think that Startup Weekend is a good way to launch a new idea.

Like what you just read? Subscribe.