So you’ve got a hackday coming up? How exciting for you.
In which case, I will assume you know roughly what to expect.
I would suggest deciding if you want to win. Hackathons are great just to participate, just for the experience, networking, and enjoyment! If so, feel free to skip this post.
And now it is just us, let’s crush the people that just left and everyone else.
Here are my hacks to maximize your chances of winning.
Disclaimer: All hackdays are different. I have tried to keep this advice general, but some points are worth a specific mention.
1. Demo value over everything else
Make something you can show really well, or something you can explain exceptionally well. Ideally you have some amount of both to ensure a great demo.
The harsh truth for us programmers is that your demo - not your code - is your entry to win. I have seen terrible projects win, because of a great demo, and I have seen mindblowing projects not win because of a poor demo.
This means what you show needs to be memorable. So, make something that is fun to demo. Ideally the judges can use/play/click/touch or have some sort of interaction with it. That way they can remember, ‘oh yeah they had the clicky/touchy/whatevery thing’.
From my experience, polished UIs, graphics, characters, etc., even if not technically difficult, always get significant bonus points.
2. Practice your pitch
This is sort of a continuation of #2, but it deserves to be its own hack because it is a really common mistake to not do.
Put some effort in - make some slides, and maybe a poster. Put some effort into your devpost if you need to make one. Don’t rush and do it at the end. Constantly think about what can go in the pitch as you go.
You should script your pitch, if only a little but, and you should have a run-through with your team.
Pitch to as many of the other participants as possible. It will help you hone your pitch, and will make you known (great if there is a hackers’ choice).
Do not just show what you have made. Tell the story. My advice is to include as many (and preferably all) of:
- Who are you?
- Why did you make this in particular?
- What technology did you use? Why?
- What is interesting about what you have made or how you have made it?
- What were the challenges that you couldn’t solve?
Remember, the judges often have a technical background, so it goes a long way to show you solved a real problem in a cool way.
Final advice on the pitch - and any public speaking you ever do in your life - you are talking too fast. You are always talking too fast and you can never talk too slow. Really take your time, don’t rush. Don’t be afraid of a silence whilst you are demoing something.
3. Decide your project ahead of time (if you can)
If you know the prize tracks or theme and you are allowed, you should definitely have an idea of what you are doing before you go in. You will be at a disadvantage if you don’t.
Included in this advice is know what your tech stack is, and have a backup idea - ideally one you can transition to, rather than needing to start from scratch - in case it all goes wrong.
I have seen so many teams just give up half way through because their project just doesn’t work. Don’t do that. You’ve got to be in it to win it, even if it didn’t go to plan. In fact mistakes and problems may be what win you it (see the pitching advice).
If you know you are doing something new or technical, prototype it first.
Obviously, don’t cheat, and equally don’t completely spoil the experience by trying to re-make something from memory. But it is not against the rules to know things, and it is not worth gambling on some technology or idea you have never touched before.
4. Play to your team
If you know them ahead of time, fantastic, but either before the event or right at the start, identify what your team members are good at. There is no point getting someone to learn something new if someone else already knows how to do it.
As some sub advice, if you can pick your teams, it is extremely helpful to have someone who can present well, and someone who can create good graphics/UI/design.
5. Use ‘Agile’
This may be more applicable for a University style 24 hours plus style of hackathon, but I highly recommend using all the Agile buzz words.
Make tickets, have a kanban board, do regular ‘stand-ups’ (I have found every 2-3 hours is good).
It will give you a good structure and prevent your team getting tunnel visioned or not communicating. Plus, it automatically gives you some things to show off in your demo/write-up.
I hope you find these hacks helpful, and maybe different from the standard advice you will find out there!
If you want some inspiration, you can read about my winning project for Bath Hack 2025 here.
Thank you for reading! Do get in touch if you think I don’t know what I am talking about, or if you want to say something nice (hello@joshuahitchon.com).
Happy hacking!
- Josh