Roughly a third of first-time teams never submit anything. Almost none of them failed because they lacked skill — they lost hours to problems that were entirely preventable the week before. Here is how to not be one of them.
One week before
Install everything and confirm it runs
Not "download it". Actually run a hello-world. The classic first-hackathon disaster is spending hour 3 fixing a Python path or a Node version instead of building.
- A code editor — VS Code is the safe default
- Git, and confirm
git --versionreturns something - Whatever runtime you plan to use — Node, Python, or your language of choice
- A GitHub account, with SSH or a personal access token already working
- A screen recorder for the demo video — OBS is free, or your OS's built-in recorder
Push one test repository
Create an empty repo, commit one file, push it. If authentication is going to break, it breaks now instead of at hour 34 when you are trying to submit.
Decide your stack in advance
Do not evaluate frameworks during the event. Pick what you already know, even if it is "boring". A hackathon is the worst possible time to learn a new framework — you get the learning curve and the deadline simultaneously.
Three days before
Sort out your team
If you are joining solo, use the event's team finder early rather than at kickoff. Aim for complementary skills rather than four people who all do the same thing. A team of three where one person can design and one can present will usually beat a team of four backend developers.
Agree on roles, loosely
Not rigid job titles — just make sure somebody owns each of these: the core build, the README and submission, the demo video, and keeping an eye on the clock. The last one matters more than it sounds.
Read the judging criteria
Actually read them. They are the marking scheme, they are published in advance, and most teams never open them. If presentation is 20% of the score, that tells you to spend real time on the video — which most teams do not.
The day before
- Sleep properly. The single highest-value preparation step, and the one people skip because they are excited. You cannot bank sleep during the event.
- Tell people you are unavailable. Family, friends, society commitments. Being pulled away for four hours mid-build kills momentum badly.
- Sort out food and water in advance. Decision fatigue is real and you do not want to be solving "what do we eat" at hour 20.
- Check your internet, and have a backup. Mobile hotspot on a different network if you can. This is the most common cause of a lost submission.
- Charge everything. Laptop, phone, power bank.
The six mistakes that account for most failures
1. Spending too long choosing an idea
Cap it at 60 minutes, hard. A decent idea started at hour 1 beats a great idea started at hour 6.
2. Scoping far too big
Whatever you think you can build, halve it. Then ask what the single smallest version that still demonstrates the idea would be, and build that first. Extra features are a bonus, not a foundation.
3. Not committing code until late
Commit and push every hour or two. Losing six hours of work to a crashed laptop at hour 30 has ended more hackathon projects than any technical difficulty. It also gives judges the commit history they use to verify the work happened during the event.
4. Leaving the demo video to the last hour
It always takes longer than expected — recording, re-recording, uploading. Start it at least four hours before the deadline. It is 20% of your score.
5. Being stuck silently
If you have been stuck for more than 30 minutes, ask a mentor. That is what they are there for and they are not judging you. Teams that ask questions early consistently finish; teams that quietly struggle for four hours often do not.
6. Adding one more feature at hour 34
Do not. Freeze the build, package what works, submit early. Every experienced participant has lost a project this way at least once.
What to have open during the event
- The event's help or mentor channel — pinned, not buried in a tab
- The judging criteria page
- A shared document for your team's notes and README draft
- A timer or clock showing time remaining, visible to everyone
A realistic expectation to set for yourself
Your first hackathon project will be rougher than you would like, and you will finish it slightly embarrassed by parts of it. That is the normal, correct outcome — and it is still more than most of your batch will have built by the end of first year.
Aim to submit. Winning is a separate conversation you can have at your second one.