How to Win a Hackathon: 5 Steps From an Idea to a Great Demo

AngelHack has run hundreds of hackathons across 100+ cities since 2011, which means we’ve watched a few thousand teams work against the same clock. The teams that win a hackathon are almost never the strongest engineers in the room.

They’re the ones who settled what they were building while everyone else was still arguing about it. Raw talent will get you a working prototype by the deadline, but deciding early is what gets you something you can put in front of a judge without apologising for it.

Here are five steps, mapped to the clock you’ll actually be working against.

Step 1: Lock the hackathon problem in the first hour

Write one sentence naming the problem, the person who has it, and what changes for them once your app exists. Do that before anyone opens an editor.

Most teams lose the initial phase deciding what to build, because five ideas sit on the table and nobody wants to cut four. A quick way to check you’ve committed: two people write the problem statement separately. Different users or outcomes means the decision hasn’t happened yet.

The strongest ideas usually come from a problem you already had. For example, Eggologic team took second in the Sustainability track at Hedera’s Hello Future Apex Hackathon with a system they needed for their own recycling operation in Uruguay, where proving their environmental impact meant a formal audit costing north of $10,000. Their advice to first-timers was blunt: teams starting from zero are inventing a problem and a solution at the same time, on a clock, and that’s two jobs when you only have hours for one.

An unlocked problem never stays closed. It reopens around hour 30 as somebody’s better idea, and it always reopens as something bigger than what you originally agreed to.

Step 2: Scope to one demoable path

Cut everything except the single path you can show working end to end in three minutes, covering one user, one action, and one visible result on screen.

That path is the only thing you build. Everything sitting outside it becomes a line in your pitch or a slide, both of which cost you minutes instead of hours.

The mistake we watch teams make at almost every event is building the parts nobody will ever see. Login flows, admin panels, a settings page with four toggles that do nothing. The window closes with the actual feature half-finished while the authentication works beautifully for a demo that never touches it.

Write the demo script before the build starts, then build only what the script requires. Your path needs to cover:

• The moment the problem shows up for your user, stated in one line
• The single action they take inside your app
• The result appearing on screen, visible without you narrating over it
• One fallback if something upstream fails during the run
• The handoff into whatever you’re claiming happens next

Anything that never reaches the screen scores nothing, because judges can only credit the parts of your build they can actually see working.

Step 3: Build in parallel without drifting apart

Divide the modules by who’s strongest where, then settle how you’ll stay connected while you’re apart. Handle the second part before anyone starts building, because you won’t have the attention for it once the clock is running.

Four practices that hold up under pressure:

• Log blockers in writing. Post the current problem along with everything you’ve already tried, so whoever picks it up gets the full context without a re-explanation. Debugging time stops disappearing into catch-up conversations, which matters most in the last twelve hours.
• Fix your check-in times. Two or three scheduled syncs work better than an always-open call that nobody joins. Cross-functional teams drift fastest in the quiet stretches, and a missed assumption compounds for hours before anyone notices.
• Integrate early and often. Modules that meet for the first time at hour 40 don’t converge, they collide. Get a broken version of the whole system running by the halfway mark, then improve it in place.
• Go to mentors before you’re stuck. They’ve seen the failure you’re about to hit, usually several times over. Asking early costs ten minutes of your time, while asking late can cost you the submission.

Team Pandamonium won the Novice track at BrainHack TIL-AI 2026 on their first attempt at machine learning. After the opening discussion everyone went off to their own task, and they “all felt alone with our own problems.” Logging blockers in writing is what pulled five workstreams back into one build.

Step 4: Use AI tools the smart way

Read the rules first, then decide where AI belongs in your build. Most events in 2026 permit coding assistants on one condition: you disclose what you used, and you can explain the code you submitted.

That condition is where teams get caught. Judges ask how a component works, and an answer that starts with “the model wrote that part” reads as a build you don’t own. Some events go further and restrict assistants to boilerplate, so check your specific rules rather than assuming the norm.

Where AI reliably buys you hours:

• Scaffolding and boilerplate. Project setup, config, routing, API clients
• Interface work. Layout, components, and styling, so your demo looks finished without a designer on the team
• Test and seed data. Realistic sample data for a demo is tedious to write by hand
• Submission material. First drafts of your README, project description, and demo script

Keep the core logic yours, since that’s the part a panel will question. Whatever you use, note it in the README before the deadline rather than trying to reconstruct it afterwards.

Step 5: Prepare and deliver the demo

Treat the demo as a scheduled block of work rather than something you improvise once the code freezes. Give it three hours minimum, and put it in the plan on day one.

Read the published criteria for your event, since most teams never look at them. Rubrics vary, but they usually consider four aspects.

• Problem fit. Whether your build answers the stated theme or track
• Technical execution. Whether it runs, and whether it holds up when someone asks how
• Demo completeness. Whether a judge can see the outcome rather than hearing it described
• Viability after the event. Whether there’s a credible path from prototype to something real

Build a three-minute structure against those four criteria and hold to it. Thirty seconds on the problem and who has it, ninety seconds of live demo, thirty on how it works underneath, and thirty on what happens next.

Then rehearse it out loud, timed, on the machine and network you’ll present on. Run it three times, and write down the three questions you least want to be asked.

On the day, freeze the build an hour before your slot and present the version you rehearsed. Keep a fallback video open in a tab, name one presenter, and test the hardware on the venue setup. Our 10 hackathon demo tips from behind the scenes covers the rest.

Conclusion

Nobody’s first hackathon goes to plan, and that’s a good reason to sign up for one. You’ll learn what 48 hours actually holds, which stack you’re fastest in, and how your team works when the integration fights back. That knowledge only comes from having done it.

Teams we meet at AngelHack events often come back the following year as finalists, carrying everything the first attempt taught them. Your next hackathon can be where that journey starts.

FAQs