Previously I've posted about what is a hackathon and why you should go to hackathons. This post is about some points that you should concern if you really want to win a hackathon.
I'm going to write this as a series of posts because I might need to describe some details for each area you have to concern. So, let this be the first post of the series.
There can be two types of wins.
1. Unexpected wins
I'm not ashamed to say most of the wins I've had from hackathons are unexpected. Yet they are the best! because you never expect to win at all. You go to a hackathon without planning (sometimes without even knowing much about it) and you find random people as a group, develop something spontaneous. Somehow it turns out to be a great idea and a great hackathon project. And you get really awesome gifts too.
2. Well planned wins
This is like training for an examination. You have to do your homework. You have to learn about the event, technology, have several concepts, do some POCs beforehand, and plan everything well.
However, it doesn't guarantee that you will win for sure because ultimately it is like a competition and it is not possible for everybody to win.
Still, preparing for a hackathon will increase your chance of winning.
How I can plan to win a hackathon is based on the traits of unexpected wins and by observing and analyzing a number of hackathons and winning teams, their projects, etc.
I'm going to sum up, some of the tricks and preparation points when and if you are really planning to win a hackathon.
This can be argued in both ways, do you really have to think about it if you are participating just the sake of experience? Or to win this in the first place?
It is totally fair to argue not to consider the prize, ultimately you may end up with a cool idea and a great experience, maybe the prize too if you win.
But if the prize is a motivational factor. If the prize is better and there are multiple gifts for multiple places, the chance of getting a prize is higher. So lesser things you have to lose.
And if the prize is too low and the number of prizes is limited, even if you win and if it is not worth the effort (unless you are really satisfied with your project and the idea) you will not have much of a motivation to win at all.
For me personally, the winning prize or the award of a hackathon is one of the key motivational factors to win or at least plan to win a hackathon.
See if they are selecting multiple winners. For instance, if they are selecting 4 or 5 places for each theme or topic, the chances are higher.
And if they are providing some additional gifts like T-shirts, Gift vouchers, or at least a pen drive, then it wouldn't be so bad right.
This step is basically to study about the hackathon you are thinking of to participate in. You just have to spend a little while reading about the event. Normally you would read about the location, who is sponsoring, technology, theme and all. What I'm asking you is to check a little bit more about it.
Technology - Some hackathons are limited to a certain technology or platform. In that case, you have to have a better knowledge of that if you are thinking of winning.
Past events - You have to study past events if you are thinking of winning. You will be able to find this information on their blogs or social media.
Past winning projects - You definitely have to find them out if you want to win. Check how they match with the hackathon themes and topics. How the user interaction was. Great if you can see some of their demos and presentations too. So you can get an idea about the scope and expectations of a winning project.
How to submit - You may miss this information over the excitement, but it is critical to know this procedure early enough. By the time you think of how to submit your work, it could be at the last moment and you may be already exhausted and sleepy with the hard work. It would go in vain if you didn't follow the proper submission procedures. Submission procedures may include hosting your app in a specific environment and/or submitting a how to use guide etc. If you are not familiar with the hosting platform they are asking you to host, it would be hard to learn it at the last moment. Therefore it will be better if you do a couple of test projects on your own and host them in the specified platform just to practice.
This is one of the most important areas you have to concern. Everything else would build upon the idea that you select. It wouldn't matter how technologically advanced your project is unless you have a great idea or a project proposal.
When you think of a project for the hackathon, normally you will have to select a theme that is given from the organizing team. It could be to solve a social issue, timely topics, fun activities, etc.
Fun activities would be something you can find common in most hackathons. When u analyze the winning projects, most of them would fall into timely topics or fun activities categories. It doesn't mean other topics won't win but think about it as a way of gaining popularity. The more your user base is, the more your app will be a success. To have a wider user base, your app has to be capable of being used by anybody. If you take a really narrow and specific problem statement to solve with your app it naturally limits its usage to a specific user base.
Eg: If you build a cool debugging tool for NodeJS development, it will be limited to the Node development crowd.
If you develop a cool app to find about rare wildlife sightings, only a specific group of people would be interested in that.
If you build a great app to notify about astronomical events like shooting stars, comets, or Lunar eclipse, only a really small crown would be interested in using that.
It would be great if it falls into one of the themes given by the hackathon organizers and the theme is very specific about it. Otherwise, if the judges are not much familiar with the problem statement, the chances are low for a win.
If you go to a problem statement where it is applicable to anybody without any specific field, there's a higher chance of making it popular and also win it.
For instance, you can think of something like reminding your grocery list. Or an app to keep you notified about the movie times of your favorite theaters. Or even an app to find the cheapest gas station near you. The more generic your problem statement be, the wider the userbase you have.
Do not re-invent the wheel!
Even though you consider a generic idea that can have a huge userbase, you shouldn't re-invent the wheel. You shouldn't select an idea where there is already a famous app/solution is available.
Eg: You don't want to build something like Uber or Instagram, not even with a slight improvement.
Because even if you do a small change and try to convince the judges, it will be really hard to convince somebody. And the users also wouldn't want to switch to your app from a well-established app just because of a tiny change.
KISS principle 💋
The KISS (Keep It Simple and Stupid) principle is an old design principle noted by the U.S. Navy in the 1960s. However, it can be applicable to anything at all, even for a software project. And even for your UI.
Just as the name implies, it means you have to keep your app as simple as possible. So, it has to be simple enough for anybody to understand. Stupid enough for anybody to use.
In other words, it says that the app is more effective when you keep it simple, and it should avoid unwanted complexities.
Features and the scope
The project shouldn't be filled with all the features you can think of. You should focus only on one or two key features. If you try to implement 5,6 features or more you won't be able to complete them successfully within a short time.
You have to identify one or two key features and complete them. Out of that also you have to prioritize the feature that you would complete first. If you fail to finish all the features, at least you have will be able to finish the key feature of your app in that way.
From a hackathon of a couple of days, it wouldn't expect you to completely develop a full-bloomed industry-ready production level project. The expectation is to provide a POC (Proof of concept) to pitch your idea and prove that it works.
Be crazy!
The idea of the app doesn't have to be a formal and traditional piece of software that you would learn in college. It doesn't have to be the School Management system that you learned in the DB class. Not a hospital management system that you learned in the OOP class.
To be an idea hackathon worthy, it has to be crazy! Crazy in the sense, it has to be unique where nobody hardly thinks of doing it.
You shouldn't think like a typical developer or a typical user. If it is a unique and crazy idea, there's a good chance that it becomes popular and catches the attention, more chance of winning.
I'm going to stop here because I don't want to bore you with my long post.
There are several more things to cover. Read the next part in How to win a hackathon - 2
I'm going to write this as a series of posts because I might need to describe some details for each area you have to concern. So, let this be the first post of the series.
There can be two types of wins.
1. Unexpected wins
I'm not ashamed to say most of the wins I've had from hackathons are unexpected. Yet they are the best! because you never expect to win at all. You go to a hackathon without planning (sometimes without even knowing much about it) and you find random people as a group, develop something spontaneous. Somehow it turns out to be a great idea and a great hackathon project. And you get really awesome gifts too.
2. Well planned wins
This is like training for an examination. You have to do your homework. You have to learn about the event, technology, have several concepts, do some POCs beforehand, and plan everything well.
However, it doesn't guarantee that you will win for sure because ultimately it is like a competition and it is not possible for everybody to win.
Still, preparing for a hackathon will increase your chance of winning.
How I can plan to win a hackathon is based on the traits of unexpected wins and by observing and analyzing a number of hackathons and winning teams, their projects, etc.
I'm going to sum up, some of the tricks and preparation points when and if you are really planning to win a hackathon.
1. Know your prizes 🏆🏆
This can be argued in both ways, do you really have to think about it if you are participating just the sake of experience? Or to win this in the first place?
It is totally fair to argue not to consider the prize, ultimately you may end up with a cool idea and a great experience, maybe the prize too if you win.
But if the prize is a motivational factor. If the prize is better and there are multiple gifts for multiple places, the chance of getting a prize is higher. So lesser things you have to lose.
And if the prize is too low and the number of prizes is limited, even if you win and if it is not worth the effort (unless you are really satisfied with your project and the idea) you will not have much of a motivation to win at all.
For me personally, the winning prize or the award of a hackathon is one of the key motivational factors to win or at least plan to win a hackathon.
See if they are selecting multiple winners. For instance, if they are selecting 4 or 5 places for each theme or topic, the chances are higher.
And if they are providing some additional gifts like T-shirts, Gift vouchers, or at least a pen drive, then it wouldn't be so bad right.
2. Do your homework 📝
This step is basically to study about the hackathon you are thinking of to participate in. You just have to spend a little while reading about the event. Normally you would read about the location, who is sponsoring, technology, theme and all. What I'm asking you is to check a little bit more about it.
Technology - Some hackathons are limited to a certain technology or platform. In that case, you have to have a better knowledge of that if you are thinking of winning.
Past events - You have to study past events if you are thinking of winning. You will be able to find this information on their blogs or social media.
Past winning projects - You definitely have to find them out if you want to win. Check how they match with the hackathon themes and topics. How the user interaction was. Great if you can see some of their demos and presentations too. So you can get an idea about the scope and expectations of a winning project.
How to submit - You may miss this information over the excitement, but it is critical to know this procedure early enough. By the time you think of how to submit your work, it could be at the last moment and you may be already exhausted and sleepy with the hard work. It would go in vain if you didn't follow the proper submission procedures. Submission procedures may include hosting your app in a specific environment and/or submitting a how to use guide etc. If you are not familiar with the hosting platform they are asking you to host, it would be hard to learn it at the last moment. Therefore it will be better if you do a couple of test projects on your own and host them in the specified platform just to practice.
3. Find a project idea 💡
This is one of the most important areas you have to concern. Everything else would build upon the idea that you select. It wouldn't matter how technologically advanced your project is unless you have a great idea or a project proposal.
When you think of a project for the hackathon, normally you will have to select a theme that is given from the organizing team. It could be to solve a social issue, timely topics, fun activities, etc.
Fun activities would be something you can find common in most hackathons. When u analyze the winning projects, most of them would fall into timely topics or fun activities categories. It doesn't mean other topics won't win but think about it as a way of gaining popularity. The more your user base is, the more your app will be a success. To have a wider user base, your app has to be capable of being used by anybody. If you take a really narrow and specific problem statement to solve with your app it naturally limits its usage to a specific user base.
Eg: If you build a cool debugging tool for NodeJS development, it will be limited to the Node development crowd.
If you develop a cool app to find about rare wildlife sightings, only a specific group of people would be interested in that.
If you build a great app to notify about astronomical events like shooting stars, comets, or Lunar eclipse, only a really small crown would be interested in using that.
It would be great if it falls into one of the themes given by the hackathon organizers and the theme is very specific about it. Otherwise, if the judges are not much familiar with the problem statement, the chances are low for a win.
If you go to a problem statement where it is applicable to anybody without any specific field, there's a higher chance of making it popular and also win it.
For instance, you can think of something like reminding your grocery list. Or an app to keep you notified about the movie times of your favorite theaters. Or even an app to find the cheapest gas station near you. The more generic your problem statement be, the wider the userbase you have.
Do not re-invent the wheel!
Even though you consider a generic idea that can have a huge userbase, you shouldn't re-invent the wheel. You shouldn't select an idea where there is already a famous app/solution is available.
Eg: You don't want to build something like Uber or Instagram, not even with a slight improvement.
Because even if you do a small change and try to convince the judges, it will be really hard to convince somebody. And the users also wouldn't want to switch to your app from a well-established app just because of a tiny change.
KISS principle 💋
The KISS (Keep It Simple and Stupid) principle is an old design principle noted by the U.S. Navy in the 1960s. However, it can be applicable to anything at all, even for a software project. And even for your UI.
Just as the name implies, it means you have to keep your app as simple as possible. So, it has to be simple enough for anybody to understand. Stupid enough for anybody to use.
In other words, it says that the app is more effective when you keep it simple, and it should avoid unwanted complexities.
Features and the scope
The project shouldn't be filled with all the features you can think of. You should focus only on one or two key features. If you try to implement 5,6 features or more you won't be able to complete them successfully within a short time.
You have to identify one or two key features and complete them. Out of that also you have to prioritize the feature that you would complete first. If you fail to finish all the features, at least you have will be able to finish the key feature of your app in that way.
From a hackathon of a couple of days, it wouldn't expect you to completely develop a full-bloomed industry-ready production level project. The expectation is to provide a POC (Proof of concept) to pitch your idea and prove that it works.
Be crazy!
The idea of the app doesn't have to be a formal and traditional piece of software that you would learn in college. It doesn't have to be the School Management system that you learned in the DB class. Not a hospital management system that you learned in the OOP class.
To be an idea hackathon worthy, it has to be crazy! Crazy in the sense, it has to be unique where nobody hardly thinks of doing it.
You shouldn't think like a typical developer or a typical user. If it is a unique and crazy idea, there's a good chance that it becomes popular and catches the attention, more chance of winning.
I'm going to stop here because I don't want to bore you with my long post.
There are several more things to cover. Read the next part in How to win a hackathon - 2
Comments
Post a Comment