How to pitch your hackathon project in three minutes

You built something real in a day and a half. Now you have three minutes, sometimes less, to convince tired judges that it matters. Plenty of good projects lose at this stage, not because the code was weak but because the pitch was a tour of features with no story.

Here’s a structure that fits three minutes and works for almost any theme.

The three-minute structure

0:00 to 0:30: the problem

Start with a person and a pain, not with your tech stack. Make it concrete. “Small shop owners near our college track credit in a notebook and lose count of who owes what” is far stronger than “financial inclusion is a big challenge”. If you spoke to real users during the event, even two or three, say so.

0:30 to 1:45: the demo

This is the heart of the pitch. Show one complete flow, from the user’s first tap to the moment the problem is solved. Narrate what the user is doing, not what the code is doing. Keep the data realistic: a shop name, a few customers, believable amounts in ₹.

1:45 to 2:20: how it works

Now you can talk tech, briefly. One slide or a couple of sentences on the architecture, plus one thing that was genuinely hard or clever. Technical judges want to know you understand what you built; they don’t need a list of every library you installed.

2:20 to 3:00: why it matters and what’s next

Close with impact and a next step. Who else could use this? What would you build with another month? End on one memorable line that restates the problem and your answer to it.

Prepare for things to break

• Record a backup video of the demo working. If the Wi-Fi or an API fails, play it calmly and keep talking.
• Use seeded data so you’re not typing during the demo.
• Close every other tab and silence notifications. Nobody needs to see your group chat on the projector.
• Bump up the font size. What looks fine on a laptop is unreadable from the back of a hall.

Slides: fewer than you think

For a three-minute slot, four to six slides is plenty: title, problem, demo, how it works, impact and team. Use big text, one idea per slide and screenshots instead of paragraphs. If a slide needs you to say “as you can see”, it probably has too much on it.

Who speaks?

One main speaker keeps things smooth. A second teammate can drive the demo while the speaker narrates. Avoid passing the mic between four people; the handovers eat time and break the flow.

Handling questions

Q&A is where judges test whether you really understand your project. A few habits help:

1. Repeat or rephrase the question so you’re sure you heard it right.
2. Answer in one or two sentences, then stop.
3. If you don’t know, say so honestly and explain how you’d find out.
4. If a judge points out a limitation, agree and explain how you’d fix it next. A defensive answer costs more than the limitation itself.

A few questions come up often enough to prepare for: How is this different from what already exists? How would you get your first users? What happens to user data? How would it sustain itself, if it needs to?

Practise with a timer

Run the full pitch at least three times with a stopwatch, ideally in front of someone outside your team. Cut anything that doesn’t serve the story. If you keep running over, trim the “how it works” section first. Never trim the demo.

Looking for your next stage? Browse upcoming events on HackathonFinder, filter by theme if fintech or another area is your thing, and save the ones you like to My hackathons.