Most hackathons are not won in the last hour. They are won in the first two, when a team decides what to build, how it will be judged, and what the demo will look like. Everything after that is execution. If you only have time for one idea from this page, take this one: decide what winning looks like before you write meaningful code.
This guide pulls together the advice that keeps repeating across the pages that rank for this topic, including HackerEarth's tips for winning, Reskilll's breakdown of judging criteria, and organiser-written guides, then turns it into a plan you can follow from the first hour to the submission form.
Read the rubric before the problem statement
The problem statement tells you what to build. The judging rubric tells you what gets rewarded. Teams often read them in the wrong order, then wonder why a technically clever project scored below a plainer one.
Rubrics differ, and that difference matters. A rubric that gives innovation the largest weight rewards a fresh angle on a simple problem. One that leans on impact or business viability rewards a team that can describe a real user and a real benefit. Guides that summarise typical rubrics describe five buckets, with these approximate ranges:
- Innovation or novelty: about 20 to 25 percent
- Technical implementation: about 20 to 25 percent
- Impact or usefulness: about 20 to 25 percent
- Demo and presentation: about 15 to 20 percent
- Completeness: about 10 to 15 percent
Treat those numbers as a typical shape, not a promise. Your event publishes its own. Write the actual criteria on a whiteboard or in the team chat and re-read them every time the team debates a feature.
Pick a problem you can finish
A hackathon rewards a finished, working thing over an ambitious, half-built one. When you choose between problem statements, the useful question is not "which one do we most want to solve?" but "which one can we demonstrate end to end by the deadline?"
A good test comes from HackerEarth's advice: the core demo should still work if the internet is flaky, a third-party API is down, or one specific teammate is asleep. If your idea depends on all three, shrink it.
Judges also tend to reward projects with a clear user. "Would someone actually use this?" is a better filter than "is this technically impressive?" Vague impact claims such as "useful for society" score poorly. A named user and a specific saving, such as the time or cost a particular person avoids, score better. If you are still choosing a problem, our guide to choosing a hackathon problem statement goes through it step by step.
Build a team around gaps, not friendships
A balanced team beats a group of people with the same strength. A common recommendation is a strong builder, someone who owns design and user experience, and someone who can frame the problem and pitch it. That is a pattern, not a rule, but the underlying point holds: if nobody on the team can present, a good build can still lose. See hackathon team roles for how to split the work, and how to find a hackathon team if you are starting solo.
Get a working skeleton up early
By roughly the first quarter of the time, aim to have the thinnest possible version of the whole thing running and deployed: input goes in, something sensible comes out. For a 24-hour event, that means around hour six. It will be ugly. That is fine. A skeleton that works end to end lets the team improve a real thing instead of arguing about an imagined one, and it exposes integration problems while there is still time to fix them.
Design the demo before the code
Write the demo script first: the actual walkthrough you will give, in the time you will be given, step by step. Then build only what that script needs.
This single habit removes a lot of wasted work, because anything that does not appear in the demo path is a candidate to cut. It also means that when time runs short, you already know which parts matter.
When you build the demo path, optimise for the room rather than for technical purity:
- Hardcode the happy path if you have to, and be honest about it when asked.
- Mock external services that might fail on stage.
- Keep screenshots or a short screen recording ready as a fallback.
- Use realistic data rather than placeholder text, since placeholder data looks unfinished.
- Check that it works on a phone, since some judges will open it there.
Use AI tools on purpose
AI coding assistants are now part of how most teams build, and used well they save hours. Use them for boilerplate, scaffolding and glue. Write the novel part yourself, and make sure every teammate can explain what is in the project. Judges ask questions, and questions are where over-reliance becomes obvious.
Treat the last hours as a separate project
Pick a feature freeze and honour it. The final stretch is for recording the demo, testing it on the actual network and device you will use, finishing the write-up and slides, and filling in the submission form properly. Teams that keep coding until the buzzer often submit a broken build and a rushed description.
Pitch the problem before the solution
A pitch that jumps straight to features loses people. A common structure is a short framing of the problem, then your approach, then a live demo, then impact and next steps. One widely repeated suggestion is to spend roughly a third of the pitch on the problem and the rest on the solution, and to show the working product early rather than saving it for the end. If you get Q and A, answer directly and say so plainly when you do not know.
Common mistakes that cost teams the win
- Choosing a problem the team cannot finish
- Another to-do app or generic chatbot with nothing that makes it distinct
- A code-only submission with nothing to click or run
- A demo that depends on live conditions you do not control
- Mockups with no working path behind them
- Impact claims with no user and no number
- Skipping the submission because the team assumed it would not place
What to do after the event
Submit even if you think you lost, because a submitted project is an entry on your portfolio and a story for interviews. Put it on your resume with the link and one line on what you built, and see how hackathons help your resume. If this was one of your first events, choosing the right hackathon matters as much as how you play it, and our upcoming hackathons page is the place to find the next one.