We won 1st place out of 23 teams, with over 200+ participants at CalgaryHacks 2018.
When I said it was our first 24-hour hackathon, I’m sorry, I lied. Two of the total five team members (myself included) had previously participated in CalgaryHacks 2017. We had a great idea. However, we had an overambitious solution, we were experimenting with unfamiliar technology, and we had huge scope creep, which destroyed our team’s morale and our project unfortunately never saw the light of day. We learned a lot from this experience and wanted to redeem ourselves in CalgaryHacks 2018.
So how did we do it?
1. Form the dream team
Obvious right? Team chemistry is vital to successfully collaborate and prevent burnout on any project. Whether you registered for the hack with a team or you registered alone, there are some key things that you should keep note of when forming a team.
Ideas will pivot fast
Don’t join a team solely because of the idea. Ideas will pivot fast. If you are trying to find a team that suits you, make sure that you take the time to get to know the team members. After all, you will be spending the next 24+ hours with them. During the initial idea and pitch discussions, it is important to work together to get buy-in from every teammate on an agreed idea.
Roles
It is highly recommended that you and your team discuss your strengths to maximize the value of your solution. Having agreed roles will help alleviate the friction that is natural in this environment and create alignment. When it comes time to start hacking, it will be easier to focus.
2. Understand the theme and the judges
Our theme was released two days before the hackathon — “long-range Internet of Things (IoT)”. The theme was open to interpretation and our team tried to interpret what constitutes as “long-range”. At first, we thought that long-range meant that our solution needed to connect to the internet using either WiFi or Ethernet. This assumption made sense to our team because “short-range” IoT would presumably use Bluetooth. We shortly decided to simply end our disputes and requested clarification on the interpretation. The organizers sent an official announcement stating that “long-range” meant “cellular”. We had to scrap our original ideas and think of something new. Remember, ideas will pivot fast.
Judging
If you are presented with an opportunity to meet the judges ahead of the pitch, make sure you take the opportunity to do so. You can gain a lot of insight on what each judge is looking for. You can leverage this information to create a strategy to satisfy the judging criteria.
In our hack, we didn’t meet our judges until it was our turn to present our pitch. What should you do in this case? We thought it was safe to simply have a focused and defined problem statement, a relevant solution with a scalable and flexible technology stack, and presentation slides to organize our pitch. We focused on the quality of implementation of our solution and our pitch over an extremely novel idea.
3. Start with the pitch
You may start feeling the pressure from the ticking of time and feel the urge to start hacking. Don’t start hacking yet. Why? You will miss the opportunity to define the motivation behind your idea and your solution. Battle-test and validate why your solution solves your problem. It is also a great time to discover any inherent flaws that cant be solved by simply coding. It would have been an expensive pivot if any deal breakers were discovered in the middle of implementation.
Having a defined motivation will also strengthen and deepen your understanding of your solution to your problem and it will make it easier to address shortcomings.
Our motivation and target audience
One of my teammates’ mom owns a cabin in British Columbia, more than a 3-hour drive from where she currently resides. She is attached to this cabin because to her, it is a home away from home. She would be worried about the status of the home and would sometimes make the drive to physically verify that the house is in good standing — no leaky pipes, no sewage backup, no broken windows, and more. The status quo is an ineffective and a time-consuming solution to her problem.
Our Pitch
You own a cabin or a cottage that you wish you could visit multiple times during the year, rather than once a summer. You arrive at the start of your summer vacation hoping to escape from the busy city life. To your surprise and disappointment, you find yourself a flooded basement and a broken window. You wished you had known of these issues earlier, so that these issues could have been addressed before your vacation started.
Our pitch wasn’t the best, but it built a concrete picture for the judges to visualize and understand the motivation behind our idea and our solution to our problem. We had clearly defined our target audiences and the problems that they experienced.
Validate against other demographics
We also targeted Airbnb hosts. I had personally met two co-hosts who owned more than 8 properties across Canada. They mentioned that our solution would greatly benefit them because they had a costly experience.
A guest in one of their properties left the balcony door open when they checked out. One of their employed cleaners entered the property and found it freezing cold and closed the balcony door, leaving after their cleaning was finished. Hours later, when new guests arrived, they reported that the basement had flooded as a result of leaking pipes and had to be compensated for another place to stay. The cost here is high — the reputation, which directly affected their business, was jeopardized. The cost of repair, rework, and repaint (as a result of the humidity) were in the thousands of dollars, and removing the property from the market damaged their revenue.
Be thorough with your pitch
In our pitch, we also mentioned solutions to relevant edge cases to our problem. When we had pitched and demoed our project to the 6 industry judges, they didn’t ask many questions. Pessimistic thoughts loomed over my head, but to my surprise, one of the judges remarked, “you guys were very thorough, I have no more questions to ask. Good job.”
4. Hack. Hack. Hack. Hack.
What are you waiting for? Hack away!
Thinking about taking a break? Take a break.
Thinking about sleep? Sleep.
Everybody hacks differently. Now is a good time to disregard the expectation that you and your team will be fully productive for the full 24 hours.
Do you have 3 coffee cups and 4 Red Bulls on your desk yet? If not, then I applaud you for your lack-of-caffeinated tenacity.
It’s only for 24 hours!
As you start hacking, you will realize that 24 hours is not a long time. If you haven’t realized that yet, let me tell you now — 24 hours is not a long time.
So how do we make the most out of our time? Avoid the fluff. Don’t chase shiny objects. They have no place here. It is imperative to ignore the distractions and focus on implementing the core of your solution to the best of your ability. As you hack, you will think of other great ideas, but remember to implement the core functionality first. Don’t spend time making your code look good. Don’t spend time perfecting your user interface. Who cares how pretty the user interface is if it is not functional and interactive? Focus on what delivers the most value — in most cases, it’s your prototype’s functionality that has the most value.
This will greatly help you and your team fight scope creep. If you and your team find yourselves changing scope frequently, then do you really have a defined problem, idea, and solution? If you find yourself in this scenario, then revisit the problem, solution, and your pitch before continuing on hacking. No amount of code can fix inherent design flaws.
Don’t repeat what has already been solved
Do you need a signup and login page with working authentication for your solution? Don’t build one. Everybody knows how authentication works and quite frankly, these problems have been solved over and over again. You don’t need to reinvent the wheel to show that you know what a wheel is. I’m sure you have better things to focus on to create a functional prototype. You can explicitly inform the judges that you are assuming that authentication is handled correctly and that your application will reflect what a user will see or use once they are authenticated.
5. The final stretch
By the final stretch, I do mean that quite literally. Take this time to stretch! At this point, I hope that there was some thought put into how you and your team will present your pitch. Your patience may be running low, but I highly recommend that every team create presentation slides for the delivery of their pitches.
Focus and clarity
After 24 hours, you may be thinking, “why do we need presentation slides, why don’t we just wing it?” That’s sleep-deprivation and mixed emotions talking. Don’t listen to them. Having presentation slides organizes your thoughts with focus and clarity. This makes it very simple for you to present and also makes it very simple for your industry judges to follow along.
A valuable realization
Out of the 8 finalists in our hackathon, our team was the only team that had presentation slides for our pitch. After watching the other finalists present, we clearly saw the value of having presentation slides. Many finalists rambled on, had circling thoughts, and even paused because they didn’t know what to say next. The idea of having presentation slides is so simple, but arriving at the conclusion that it is needed is not as intuitive as you would think (especially with the pressures from the hackathon). I truly believe that we had a large competitive advantage and were scored generously as a result of delivering a well-organized and professional presentation.
6. Conclusion
Now you may be wondering — that’s it? Well kind-of yes, and kind-of no. I truly believe that a well-defined problem with a focused solution and an organized pitch delivery is what the industry judges will be primarily looking for. In 24 hours, there is a limit to what you can do in regards to technical implementations, especially for novel ideas. Of course, if the prototype of the solution is functional and has all the proposed bells and whistles, it will provide a huge advantage. However, I think that this is not the primary focus simply because most hackathons are available to people with all skill levels — from non-developers to experts. A hackathon is so much more than just hacking.
I hope that these tips help you gain some insight on how you could win your next hackathon! We had a great and enjoyable experience. We also had some scary moments where we had no functionally working — just a couple of hours before the pitches. If I have to give one last tip, it would be that you shouldn’t be afraid to fail. This will help remove a lot of pressure off of you! We originally joined this hackathon because we were all passionate about innovation and wanted to try and solve challenging problems. I want to make it clear that we didn’t join this hackathon expecting to win. We simply wanted to have some fun and you should do the same!
Our tech stack
For those curious about our tech stack, we had a very solid stack that brought our solution to life. We challenged ourselves to create something with real-time data and states, web-responsiveness, and have considerations to scale.
Particle Electron — this was the Arduino board with several sensors emitting data to our back-end server
Front-end — built with React using CoreUI (open-source template)
Back-end — built with Node.js with Hapi.js web framework using MongoDB in Docker and in AWS EC2