Hackathons are popular amongst developers from beginners to industry professionals, but you can often see the same mistakes being made by hackers of all levels at every hackathon you attend. Building a winning project is no easy task, no matter how experienced you are; here are some great ways to improve your chances of winning at future hackathons.
Think outside of the box, think better
I know, it's easier said than done to simply have good ideas. Good ideas are not only down to personal opinion, but they can be really difficult to come up with.
I suppose what I mean here is that it's important to think about what it is that you're building, instead of just building the first thing to come to mind that matches the hackathon theme, think of something outside of the box and try to consider these things:
Does it fit the hackathon theme? Hacks that don't fit the hackathon theme probably won't win!
Is it unique and original? A hack that is just the same as 5 others and serves the same purpose as a million products that already exist won't do as well as your original ideas that have never been done before or never done in the way you've done them. If you do end up building things that have been done before, try and take a look at how you can put your twist on them.
Does it integrate or use tools provided by the event sponsors? Hacks that use sponsor resources are often eligible for more categories, raising your chances of winning!
If you think about those things you can create better ideas that are more likely to impress the judges and event sponsors, making it easier for them to justify picking you to win any specific category!
Be reasonably ambitious
Ok ok, of course being ambitious is a risk, don't set yourself the goal of rebuilding the internet in 36 hours, but being reasonably ambitious is a key part of creating a winning hackathon project. Without a little bit of ambition, your project will blend in with the rest of the basic projects in the background that end up forgotten about in the end. Be reasonable, building a hacky yet functional dynamic web app is fair and achievable and ambitious, there are a lot of technical requirements but with the right skill set and tools, there's nothing to hold you back!
What I'm saying here is that a simple static site probably won't get you very far in a hackathon, but building something that has functionality (extra kudos if it would be useful in the real world as well) is enough - but as mentioned previously, make it unique, make it different and make it more all while staying on theme.
Integrate more sponsor tools into your hack
There's more to hackathons than 1st, 2nd, and 3rd. Sponsors sponsor hackathons to get you to use their products and to better incentivise you to try out their tools they often offer prizes of their own for specific categories. By using more sponsor tools and integrations you open your project up to more opportunities to win! A lot of the time, alongside learning, winning is the sole aim in a hackathon so don't disappoint yourself and increase your chances a little.
I have participated in many hackathons and often when I have used sponsor tools, I have been recognised for that and have won categories such as 'Most Creative Use of Twilio', 'Best Blockchain Project Using Hedera' and 'Best Domain Name from Domain.com'. Often these sponsors provide some pretty cool prizes too, everything from keyboards to programmable games consoles and more!
Not only does entering a sponsor category or two help you to win more often, but the experience you gain from using yet another product in your projects also is incredible and increases your employability massively as you diversify your skillset. For instance, I had never truly touched on Web3 before building my 'Best Blockchain Project Using Hedera' but using Hedera gave me some experience and a better understanding of what it is all about.
Try new things
Trying new things is a key part of hackathons - it's all about learning at hackathons, so trying new things is often highly supported. Having something cool to mention in your Devpost submission is always a good way to keep it interesting and make your project memorable. If you've always used JavaScript but want to learn to use Python, try it out, what's the worst that could happen? If you're a JS developer who's completed a project entirely using Python for the first time, that's pretty cool and a good way to impress the judges.
Write better Devpost submissions
So often I see walls of boring text on my opponents' Devpost submissions. There's nothing that catches my eye and nothing to separate different key points.
When writing my Devpost submissions I include a selection of key headings - each of which assigned an emoji to add some colour to bring its attention and better understand its purpose.
💡 Inspiration (Here I explain my inspiration for my idea and reasoning for building it.)
👷♂️ What it does (Here I give an in-depth explanation of what the hack does and how it works - highlighting why it fits the theme and my thinking behind it.)
- 📑 TL;DR (Here I use a subheading under '👷♂️ What it does' to give 4-5 bullet points explaining just the key points - the judges probably won't read your submission entirely so allow them to still get the full value out of a shortened version.)
❓ How I built it (Here I explain the tools I used, the workflow, the path taken and everything else I can think of that contributed to the building process.)
-
- 💾 Technologies (Here I use bullet points to list technologies I used, HTML, CSS, JSX, React, etc anything like that!)
- 🚀 Use of Sponsor technology (Here I make it clear which of the sponsor technologies I used to allow the judge to easily understand how I may qualify for specific categories. I also tend to add a paragraph with each one to explain its involvement in the project and why I chose to use it in that way.)
⚡ Challenges I ran into (Here I explain in a few paragraphs any difficulties I experienced, the submission shouldn't make everything look easy, this is your opportunity to show how hard you worked on your project and how you overcame challenges both big and small.)
🌈 Accomplishments that I'm proud of (In this section it's exactly what it says on the tin: what I accomplished that I'm proud of! I simply write a couple of paragraphs here to explain the things I did that am proud of. Did I fix a difficult bug? Write it down. Did I learn something new? Write it down. Did I manage to build an ambitious feature? You know what I'm doing!)
👨🎓 What I learned (Here I take a moment to simply explain everything I learned throughout the event. If I tried a sponsor's tool that I wasn't already familiar with, I'll mention it here. Tried a new language/concept/technology and learned about it? This is where that goes.)
📅 What's next for <projectName> (This section is often just a couple of lines as a self-evaluation of the project - I include things I could or would add if I had some more time or knowledge, it doesn't have to be much.)
With the use of these headings, it makes it easy to make sure everything's included in the submission so that the judges and others looking at the submission know exactly what I was thinking while building my project and the reasoning behind each decision, allowing me to convince them as to why I should win as they can fully understand my mind at the moment and be on the same page as me.
Stick to the guidelines
This one probably sounds stupid, surely sticking to the guidelines is just common sense? The times I have seen 15-minute demo videos at hackathons that have required a demo video of a maximum of 2 minutes is crazy. Keep it short, keep it on-topic, and keep to the guidelines.
The likelihood is if you don't follow the guidelines set - like time limits, themes, demo guidelines, etc. Big parts of your submission may be ignored as these guidelines are often put in place to make the judging possible to complete in due time.
See it in action
All the advice I have provided here is advice that I genuinely follow and believe in, want to see it genuinely working and winning hackathons?
Checkout my Devpost profile here:
Oldest comments (0)