Success and Lessons from Startup Weekend

December 5, 2013 Joshua Allen

At the Toronto Startup Weekend Maker Edition, my team and I created a solution called Pawly. It’s a robot equipped with a camera that allows you to check-in on your pet at home from your mobile phone. After a whirlwind 54 hours, we were extremely excited to have placed second in the competition. Here are three lessons that I learned firsthand from Startup Weekend:

1. Write it from Scratch

Time is a huge constraint in a hackathon. Early on, there will be an important decision to be made: Should we go with a library that will do everything we need it do, but that nobody is familiar with? Or should we go with a library with less long-term feasibility, or perhaps even write the code ourselves?

Given the time constraints in the case of a hacker weekend, you should almost always build the prototype from scratch or the library that teammates are most familiar with. If you don’t, you’ll spend a large amount of your already scarce time troubleshooting, which means less time coding and building the prototype.

2. Build a Prototype

Your goal should be simply to create a proof of concept; as a result, production-quality code may not be possible. That’s absolutely fine. The code you write most likely won’t make it into the final product. Even if you considered putting code from the hackathon in, you’re going to want to revisit and edit everything.

Similarly, your design isn’t going to be the most extravagant; a simple and functional user interface is sufficient in such an early stage of app development.

Lastly, if you find yourself distracted every so often, you should regroup and focus on the deliverable for the weekend: a proof of concept that you can show to potential customers and validate your idea with. (Bear in mind, you will subsequently present this deliverable to judges.)

3. Validate Your Idea

When in doubt, invest as little time and effort as possible prior to validating your idea. A lot of developers, like myself, have the natural tendency to just build stuff. Unfortunately, this could really waste your time if you spontaneously build it; the idea won’t be validated yet, and will flop on launch day.

Despite the hard work that goes into them, the harsh truth is the vast majority of apps live for a few days. I liken that to walking a hundred metres and only living for an inch. After a hundred metres of development, the majority of apps just plummet on launch day. If you want your app to go the distance, validate your idea. In a wise speaker’s words: mayflies only live for a couple of days. Try to make your app the longest living mayfly ever: make it last for four or five days.

How exactly did we validate? We spoke to our audience in two ways: we surveyed friends and family, and we pitched random strangers on the street.

The survey was an exploration into monetary expenditures onto this type of product. In this case, we asked pet owners whether they cared if they left their pets alone or not, and if they would be interested in doing something about it. We acquired feedback from 100 responses simply through e-mailing people we knew and sharing the survey on social networks.

Secondly, one of our team members hit the pavement and pitched the idea of Pawly to strangers on the street. If they liked it, he asked them for a dollar to prove that they like the idea. He ended up getting around $9.

Closing Thoughts

Creating a successful business requires many different skillsets. Developers love to build stuff and as a result put less importance on the actual business model. Going to a Startup Weekend lets you see how valuable those other non-technical skillsets are.

It takes an incredible amount of hype to get the word out about a product. A lot of developers will build something and believe that if they build it, users will come. Unfortunately, that’s not at all how it works. Getting people to adopt an app requires a lot of promotion, marketing, sales, hustle, and careful strategy.

You can still vote for Pawly – click here to make it a reality!

About the Author

Biography

Previous
Fact-based state in Rails
Fact-based state in Rails

Maybe you learned this from experience or you joined a Rich Hickey-esque immutability craze, but one way or...

Next
A Recap of DesignThinkers 2013
A Recap of DesignThinkers 2013

Co-authored with Lindsay Auchinachie   The DesignThinkers 2013 conference took place in early November in T...

×

Subscribe to our Newsletter

!
Thank you!
Error - something went wrong!