Believe it or not, it’s just not enough to have a good project.
I recently mentored students and judged submissions to the Eastern Washington University hackathon. We had 17 projects submitted, and over 20 teams that started the day out. This is the second hackathon I’ve volunteered with in the last year, and I’ve noticed a few things that really make teams stand out as contenders for a podium finish.
Originality
This one is huge – unless you have a truly game changing twist on an existing app (think dating, delivery, etc.) you’ll probably want to avoid doing what’s already been done successfully. You have to pique the judges interest, and rehashing e-harmony probably won’t do it.
This is a tough ask, very few people can come up with a truly original idea that could be executed in a 12 hour frame. I’d recommend once you choose to participate in a hackathon that you spend a lot of time brainstorming your idea beforehand.
Picking the right tool for the job
The wrong tool (or no tool) will probably add complications and time to your dev time, and a hackathon is all about doing the most in the limited timeframe. If you’re making a game, but choose to roll your own game engine (using Java and JFrame for example) you’ve now added the overhead of making your own tooling compared to using Godot or similar game studios.
If you’re making a web application, and you choose to use plain HTML/CSS/JS instead of Vue, React, or Angular (or whatever SPA framework you’d like) you’ve chosen no tool. The same goes if you choose to use a basic server like Flask instead of using Django, Laravel, or Rails.
The exception here is if you decide to make your own web framework or game engine, in which case building from the ground up is probably your best approach.
Tell a story
A big part of presenting is telling a story. What problem does your project solve? Boredom, loneliness, confusion, disconnection? How is your project going to make an impact? Sometimes, it’s not enough to show people a product? Sometimes, they need a little (or a lot) of guidance before they appreciate what you’ve built.
Bonus points for appropriate comedy. Making people laugh never hurts.
Presentation
So you’ve got your project, you can explain the need it fills, and now it’s time to talk about what your project does – and here’s the important part. You must must must focus on WHAT your product does, not HOW it does it. Chances are, there are at least a dozen ways you can put together technology to deliver your product. There will probably be ways in the future that just haven’t been invented yet. What matters is what your technology can do, and I’ve found that many judges don’t care about how your product works behind the scenes.
I do. Given the time, I’d love to rip into every project presented, and get a real feel for if the maker(s) of the tool actually understand how it works, or if they just vibe coded for 12 hours and managed to come up with something that works, with little to no understanding of the technological underpinnings.
What did you learn?
This one is easy – throw in a 15-30 second blurb about some new tech that you learned about that day, or a new IDE feature you used, or anything new to you that day.
It shows growth, demonstrates the willingness to learn, and hopefully instills within the judges that you made and effort.
I hope this was, at the very least, helpful to you. I’d be flattered if you found it interesting 🙂