A hackathon is a deadline with a stage attached. That is the useful way to think about it.
The event is not really testing whether you can build something enormous in thirty-six hours. It is testing whether you can decide what not to build, divide the work, and finish a working prototype that runs.
Before the event
Read the rules twice. Track, team size, eligibility, submission format and judging criteria are usually published, and teams lose points for ignoring them.
Prepare the boring setup in advance:
- A working development environment on your own machine.
- Accounts for the tools you expect to use, created before the clock starts.
- A Git repository with a README skeleton.
- A deployment path you have already tested with a hello-world app.
Form the team before the idea
Four people with overlapping skills will struggle. A workable team covers product thinking, frontend, backend or data, and someone who can present. If you are a team of one, choose a smaller scope — not a bigger effort.
Agree on a decision rule early. “The person who writes the code has the final say on scope” is a reasonable one. So is a two-minute vote with no re-litigation.
Scope an idea you can finish
The best first hackathon project has one clear user, one core action, and a visible result.
A workable scope:
- One user journey, start to finish.
- One integration, not four.
- Real data if you can get it; clearly labelled test data if you cannot.
- A presentation you can run offline.
An unworkable scope: “a platform that connects students, colleges and recruiters with AI matching, payments and a mobile app”.
Write the presentation script before you write the code. If the script has more than five steps, cut the idea.
A realistic timeline
| Phase | Spend |
|---|---|
| Problem and scope | First 10% |
| Skeleton that runs end to end | Next 30% |
| Core feature | Middle 35% |
| Polish and presentation prep | Final 25% |
The skeleton matters most. A project that runs end to end, even with ugly internals, can be improved. A beautiful half-system cannot be demonstrated.
What judges actually score
Criteria vary, but the common axes are:
- Does it work? A working prototype beats a slide deck. Always.
- Is the problem real and clearly stated?
- Is the implementation honest? Judges notice hardcoded values presented as live data.
- Is the scope appropriate? A finished small thing scores better than an unfinished large one.
- Can you explain it? The team that understands its own code answers follow-ups well.
Practise the presentation out loud, twice, with a timer. Rehearse the failure path — what you will say if the network drops or the API rate-limits you.
Etiquette that gets remembered
- Do not take credit for work you did not do.
- Use open-source libraries with their licences respected.
- Keep the repository public if the rules require it, and commit as you go.
- Be generous to other teams. The community is small and people remember.
After the event
Finish the README, add screenshots, and deploy the project even if you did not win. A hackathon project that becomes a portfolio piece is worth more than the certificate.
Write down three things: what you would scope differently, what technical gap slowed you down, and who you want to work with again.
The short version
Prepare the environment, form a balanced team, scope one journey, build the skeleton first, rehearse the presentation. Finishing is the strategy.