TL;DR
- Most hackathon demos run between two and five minutes, with three minutes the most common slot
- In a three-minute slot: 30 seconds on the problem and solution, 90 seconds on the live demo, 30 seconds on your tech stack, 30 seconds on what comes next
- Read the published rubric before you start building
- Save a recorded backup of your demo
- The checklist below covers the final hour
A hackathon demo is the short presentation, usually two to five minutes, where your team runs its working prototype for judges and makes the case for it. That slot is where 36 hours of building gets its outcome.
After running hundreds of hackathons globally and watching thousands of participants present, we’ve found the teams who do well share a short list of habits that take under an hour to pick up. Here are ten of them, along with what’s changed for demos in 2026.
The structure of a good hackathon demo
Three minutes is the most common demo length we see, and it carries four distinct tasks.
0:00 to 0:30
Introduce the team, name the problem, and give the solution in one line.
0:30 to 2:00
Run the live or recorded demo, which is the part judges came for.
2:00 to 2:30
Explain the tech stack and the part that took real work.
2:30 to 3:00
Outline next steps, scaling, and business impact.
The proportions matter more than the minutes. In a two-minute slot, fold the tech stack into the demo and narrate the hard part while it’s on screen. In a five-minute slot, extend the demo and the next-steps section rather than the introduction, since a longer setup gives judges more to sit through before they see anything run. Whatever the limit, keep the demo itself at roughly half the total runtime.
What judges score in a five-minute window or less
Judging sheets differ from program to program, and the good news is that the criteria underneath them are remarkably consistent:
🛠️ Working prototype
Something runs live in front of the judges, even partially, and a rough build that functions will score above a polished set of slides describing one.
🎯 Theme fit
The solution maps to the challenge statement and respects the constraints it sets, whether that’s a specific dataset, platform, or user group.
🧠 Technical depth
The hardest engineering decision gets named out loud, so if the difficult work sits in the backend, say so while the frontend is on screen.
📈 Viability
There’s a named user, a clear use case, and a plausible next step after the program ends.
💡 Clarity
A judge from outside your domain could restate what the product does five minutes after you finish.
Most programs now publish the rubric alongside the challenge brief. Reading it on day one is the foremost advantage available to any team, since it tells you what to build toward before you write a line of code.
The hackathon demo-day checklist
The hour before you present is when small oversights turn into lost seconds, and lost seconds come straight out of the demo. Hand that last hour to the presenter and work through this list together.
Each item takes a minute or two, and together they clear the ground so the presenter walks up thinking about the pitch rather than the setup.
10 hackathon demo tips, from kickoff to the last minute
These run in rough chronological order, from the first hour of the program to the last minute before you present.
BEFORE YOU BUILD
1. Assign the presenter at kickoff
No team waits until Sunday to decide who writes the backend, and the pitch deserves the same clarity. Naming the presenter in the first hour gives that person the whole program to collect material. In cross-functional teams the strongest presenter is often a designer or a domain expert, so pick for clarity rather than seniority.
2. Write pitch ideas down as they come up
The line that ends up carrying your pitch usually arrives somewhere in the middle of the hacking, and in most teams nobody thinks to write it down. Keep one shared note open for the whole program and drop ideas into it as they land. A recording or AI note-taker running during team discussions does the same job without anyone having to remember. By the last few hours, the presenter is editing raw material rather than starting from nothing.
BUILDING THE PITCH
3. Focus on storytelling
Your audience sits through a lot of demos in a row, so give them something with a shape rather than a list of features. Open with a frustration the room has felt, then build the whole demo around the moment your product resolves it. Everything before that turn is setup and everything after is payoff.
4. Name your model and how you evaluated it
This is the biggest change since we last updated this article. Nearly every submission now uses AI somewhere, so telling judges you used a large language model gives them nothing to score. Name the model, say why you chose it over the obvious alternative, and explain how you checked output quality.
5. Use guideposts and let your brain fill the gaps
Memorising three minutes of copy takes energy you will not have on Sunday, so memorise the turns instead. Write down the four or five phrases that move you from one section into the next and treat those as route markers. A pitch is a story, and you know this story better than anyone in the room.
6. Share more than what’s already on screen
Judges watch and listen at the same time, so don’t spend words describing what’s already visible. Nobody needs a narrated tour of a form being filled in or an upload bar crossing the screen. Use those seconds for the work they can’t see: the retrieval pipeline, the model routing, the dataset you cleaned by hand. Slides are optional, though one at the start helps frame the problem before the prototype takes over.
7. Make it fun and memorable
What judges remember an hour later is rarely the most polished demo in the room. Give them one moment worth recalling instead of scattering effort across the whole run, whether that’s an audio treatment, a deliberately absurd test input, or a side-by-side against the old way. The moment should show your product doing something, not sit alongside it as decoration
BEFORE YOU PRESENT
8. Rehearse out loud, ideally to someone outside the team
Running the pitch in your head skips between ideas without connecting them, so the transitions go untested until you’re standing up. Say it out loud at least once, and if you can, say it to a mentor on the floor, a friend, or an organiser. Your own team can’t hear it fresh anymore, while a first-time listener asks what judges will ask. Time each pass, because the first run tells you what to cut.
9. Anticipate the questions judges will ask
Q&A often runs as long as the demo itself, and it’s where a good pitch turns into a convincing one. Judges tend to ask the same handful of things: who the user is, who pays, what was real versus mocked, and what you’d build next. Talk those through as a team beforehand.
10. Keep a recorded demo ready
Venue wifi is unpredictable and live APIs could time out at the worst possible moment. Record a clean run of your demo the night before, save it locally, and swap in local fixtures for anything that depends on a network call. You probably won’t need it, and knowing it’s there is what lets the presenter show the build they’re proud of.
Where a strong demo takes the hackathon project
Three minutes is enough time to show a working prototype, explain the hard part, and point at what comes next. Teams who plan the pitch alongside the build consistently walk away with better outcomes and a clearer post-event path for the project, because the thinking that makes a demo land is the same thinking that turns a prototype into a pilot.
For builders preparing for their next challenge, the event calendar shows what’s open now, and the AngelHack blog has more resources and stories from hackathon winners.
FAQ
How long is a hackathon demo?
Most hackathon demos run between two and five minutes, with three minutes the most common slot and a short question period afterwards. Virtual and hybrid programs often use recorded video submissions in the same range, so check the program brief, because the limit is usually enforced.
What should a hackathon pitch include?
In a three-minute slot, spend 30 seconds on the problem and solution, 90 seconds on the demo, 30 seconds on your tech stack, and 30 seconds on next steps. Judges want to see the prototype run, understand where the hard technical work sits, and hear a credible path to a pilot.
Who on the team should present the demo?
Assign the presenter at kickoff rather than in the final hour. The best choice is usually whoever explains the project most clearly to someone outside the team, and that person is often a designer or a domain expert.
How much time should you set aside to prepare a hackathon demo?
Under an hour of rehearsal across the program, plus the final hour for logistics. Two or three timed run-throughs, one practice pitch with a neighbouring team, and a pass through the checklist covers it.
Do you need slides for a hackathon demo?
Slides are optional, and most strong demos use one or two at most. The prototype carries the pitch, so keep slides to the problem statement or an architecture diagram. Check the brief, since some programs ask for a deck.
What questions do hackathon judges ask?
Common questions cover market size, who pays, what’s real versus mocked, and what the team would build next with more time. In AI-themed hackathons, expect questions about model choice, data sources, and how output quality was measured.
