How to win a hackathon. Here is what separates teams that place from teams that don't.

Since last year I started going to hackathons regularly. Since then – 8 hackathons, 6 placements, and a fresh 2nd place from last weekend.

After all those hackathons I ended up having a pretty clear picture of what separates teams that place from the ones which don’t. It all comes down to things that coders mostly overlook. Spoiler: Quality of your code or complexity of your solution has nothing to do with it.

Build your team like a startup

If your team is a group of coders only where nobody can present, you shoot yourself even before you write a single line of code.

Participating in a hackathon is similar to building a startup. Users don’t care about the technical execution alone – same with judges. The judges are usually managers or executives. They don’t code. They don’t want to hear about your database, RAG pipelines or APIs. They need to understand the problem and trust that your solution solves it.

Here is how our team is structured: I’m the tech lead and decision maker – I distribute work, make direction calls, handle the codebase, and talk to mentors. My teammate handles design, the pitch, and co-owns decisions with me. Then we have two engineers – one is focused on frontend, one on backend. Four people, clear roles, no confusion.

From my experience the optimal team size is 3–4. Larger teams require much more coordination for which you don’t have time.

The most important member of your team is the one who presents. They don’t have to understand every technical detail – but they must be comfortable in front of a crowd. My teammate spent five years in theatre – that makes him very good at that job. However, that’s not a requirement. Look at your friends who are more comfortable when presenting in the class, or maybe you have a friend that can talk really well. Bet on that person. If you are an engineer you must understand that you cannot handle everything. Most engineers don’t pitch well, and it’s completely normal.

Once you have your team, someone has to lead. It should not be a debate between four people on which direction to choose. In my team that’s me and the guy who presents. We talk to the mentors, make sense of what we’ve heard, and make the call. The rest of the team trusts that decision and executes. There’s no committee vote. There must be a clear structure in the team as well as mutual trust.

Do your homework before the event

A lot of information about the hackathon is available before it starts. Most teams ignore it. Don’t.

If there is an in-person event – spend you time and come, even if the hackathon is not in your hometown. Just be serious about it and show up early. Yes, you will spend more time but you increase your chances.

I research the topics, the challenge briefs, and especially the mentors. Understanding who the mentors are lets you understand what will resonate with them. You should not build for an abstract jury. You must build for specific people.

I also prepare code ahead of time. Take a guess at what you’ll need and just start. If the project will need scraped data, scrape it before the event. If you’ll need a map setup or some complex auth flow, prepare it in advance. You don’t want to waste your first four hackathon hours on boilerplate.

When you arrive, the first thing you do is talk to mentors. Not code. Talk. Listen to everything, understand what the hackathon is actually about, what the judges care about.

When there are multiple challenges, we go with the one that has the most impact. It’s easier to defend in the pitch — “we tackled X because it affects Y million people and Z amount of money is lost because of it” sounds better than “we thought it was interesting.”

I learned this the hard way. Our second hackathon — right after our first win — we came in with our ego higher than Mt. Everest. We didn’t do the things that had worked: talking to mentors, showing demos at our table, building rapport with anyone who walked by. We thought the product would speak for itself. It didn’t.

Go all in or go home

My rule – if you decide to show up, you don’t sleep until it’s done.

The first 24 hours – and especially the first night – you go all in. By morning of day two, you must have something you can present. Not finished, not polished. Only presentable.

Day two morning is for finishing touches and any features mentors specifically requested during their sessions. As soon as possible, you must shift your focus to the presentation. Not at the last hour.

I do a lot of coding myself, but I also check in with the team every four hours. Where are you at? What’s blocking you? If someone is stuck on something I can do faster, I’m honest about it — I take it over and give them something else. There must be no ego. The goal is to ship.

Energy will crash. At hour 30 someone on your team will want to sleep, slow down, or mentally check out. This is normal and you should account for it. Sometimes you just quietly pick up the work and finish it yourself. No drama, you came for a win.

Scope is the other thing you must control ruthlessly. Cut down your vision to the smallest thing that can demonstrate it. If you have a bigger picture in your mind, mention it in the pitch — “we built this in 48 hours, here’s what can come out of it.” Yes, it is generic, but it shows you care.

What you must never do is pivot mid-hackathon. If you chose your direction wisely at the start, you won’t have to change direction. Mid-hackathon you only cut scope, never change direction.

The presentation is half your score

Most teams treat the presentation as an afterthought. It’s not. It is actually 80% of success.

Imagine a fine dining – you expect a top quality meal which is served beautifully. You would not have the same experience if you are brought steak on a plate that looks messy and distasteful. Same with your hackathon project.

How to serve you project?

1. Show a video, not screenshots. If you built something dynamic — anything with movement, interactions, a live map with data flowing through it — record it. A video playing behind your presenter while they talk keeps judges engaged even if they zone out on the words.

   I use Cursorful for recording in browser because it allows to add zoom effects easily. You may also look into other options, there is plenty of them like ScreenStudio or Cap. You can also just record a simple video using any screen recorder. Effects are not mandatory, but they make it look more impressive.

   Tip: PowerPoint supports both autoplayed videos and GIFs. I usually go with GIFs. To convert videos to GIF I use free tool Gifski.

2. Structure it like every good presentation. Problem statement first, then solution, then bigger picture. Start with the problem the hackathon was about — make it specific and ideally engaging, a joke, an unexpected angle, something that wakes people up. Then show your solution. Then zoom out and paint the picture of what this could actually become. That’s it.

3. One person presents. Not two, not three. One. No sharing the microphone, no attention splitting. One person owns the stage. After the pitch it’s absolutely alright to come to stage yourself and answer technical questions though.

4. Build rapport during the event, not just at pitch time. The judges and mentors see dozens of teams. Be memorable before you even get on stage. Talk to them during the event. Have a memorable team name. Put something weird on your table. When you get on stage, some of those judges already know who you are.

5. Present from your own machine. This one hurt once. We had a perfect pre-pitch — the judges were visibly impressed, we had the energy, we were going to win. Then the final presentation lagged. The organisers ran it from their machine using the browser version of PowerPoint instead of the desktop app. It froze, killing our pitch entirely. This could have been avoided by just running it from our Mac.

6. Prepare for the QA in advance After your final slide, add hidden slides with answers to the obvious questions — pricing, limitations, future plans, how you’d scale it. When a judge asks something you anticipated, you flip to a slide with the answer already on it. People immediately perceive you different because you came prepared.