Guides
How to make a hackathon project pitch that people will remember
The structure of a three-minute presentation, why demos are more important than slides, and common mistakes that cause strong projects to lose.
The jury doesn't see how many nights you didn't sleep or how beautiful your code is. They see three minutes of your presentation and make their decision based on that. It's unfair, but that's how every hackathon works, and it works in your favor if you prepare your pitch seriously instead of five minutes before going on stage. A strong project with a weak presentation regularly loses to an average project with a good one.
Tailor your pitch to the criteria
Before writing your presentation, open the hackathon page and re-read the evaluation criteria. The jury judges based on these, so a pitch that directly answers every criterion is always stronger than one that is beautiful but misses the point. On Stavleak, the criteria are visible in advance on the event page, and if the wording is unclear, ask on the Q&A board; all teams will see the answer.
The three-minute structure
You can't tell everything in three minutes, so don't try. A simple chain works best.
- Problem. One specific pain point you are solving, with a real-life example.
- Solution. What you did, in one clear sentence.
- Demo. Showing a working product, not talking about it.
- How it works. Briefly about the technology, if there is something to surprise with.
- What's next. Where the project can grow.
More than half of the time should be spent on the problem and the demo. Talk about architecture at the end and briefly, if the jury is technical.
Demos are more important than slides
A working product on the screen is more convincing than ten slides with descriptions. Show live what really works, and don't show what is broken. If something isn't ready, work around it instead of apologizing on stage. "We haven't finished this part yet" is a phrase after which the jury mentally lowers your score.
If your project has AI
The jury has seen a hundred wrappers over chat models this season, and one more won't surprise them. Don't sell the fact that "we added AI," sell the task it solves. And remember that a live AI demo is temperamental: the model responds slowly, sometimes talks nonsense right on stage, and the internet at the venue might be weak. Prepare a recording of a successful run and a pre-thought-out example where everything works stably so you don't face a hallucination in front of the jury. We analyzed how to distinguish a project from a wrapper separately.
Mistakes that sink strong projects
- Starting with the team composition and stack instead of the problem. The jury doesn't understand why it's needed yet, and you're already talking about technologies.
- Showing code on the projector. No one reads code in three minutes.
- Having the whole team speak in turns. Let one person speak, two at most.
- Going over time. You will be stopped in the middle of the demo, and that is the worst moment to be stopped.
- Apologies and disclaimers. They lower the value of what you've done for free.
How to rehearse
Say your pitch out loud at least twice and time it. What sounds like two minutes in your head stretches to four when spoken out loud. Decide in advance who speaks and who clicks the demo. Agree on what to do if the jury asks a question you don't know the answer to: an honest "we didn't have time for this, but here is how we planned it" sounds better than trying to make something up.
Results and awards, by the way, will appear on the same event page immediately after evaluation, so you won't have to wait long for the verdict. And it's easiest to choose where to apply all this in the hackathon catalog.