How to Win a Hackathon

TL;DR Winning a hackathon is less about the most impressive build and more about scoping something you can finish, understanding what judges are looking for, and showing it off well. A small thing that works beats an ambitious thing that doesn’t, every time. The teams that place are rarely the ones who wrote the most code. They’re the ones who finished something and told its story. And the habits that help a team place are the same ones that make the whole weekend worth it, prize or no prize.

Plenty of people walk into a hackathon hoping to win, and a lot of them aim at the wrong target. They try to build the most technically ambitious thing in the room, and run out of time. The team that scoped something small, finished it, and gave a clean two-minute demo is usually the one that places. The good news is that the same habits that help a team place are the ones that make the weekend worth showing up for either way.

This guide assumes you’re already there and building. If you’re still getting ready, start with the companion guide, How to Prepare for a Hackathon. Everything below is about the hours between the first commit and the final demo.

Understand how Judging Actually Works

It’s hard to do well in a game without reading the rules first. Knowing what judges are looking for is one of the most useful things a team can walk in with, because it turns building into something you do on purpose instead of hoping it lands.

Judges typically weigh a handful of dimensions: how technically difficult the build was, how original the idea is, how polished and usable it feels, and how well the team presents it. At MLH, this looks like an even split with judges weighing originality/creativity, technical complexity, adherence to the hackathon’s theme, and practical implementation evenly.

One thing worth knowing early: the main prize isn’t the only prize. Sponsors run their own tracks with their own criteria, and side categories reward things the overall judging might not. A team that doesn’t win the whole event can still win a track, and plenty do. Read what’s on offer at the start, not the end.

Scope Something You Can Finish

Over-scoping is the most common reason teams don’t place. The idea feels achievable at hour two and impossible at hour 30, and by then there’s no time left to recover. The fix is to decide, early and honestly, what “done” looks like, and to make that version small.
A finished ugly thing beats an unfinished beautiful thing, every single time. Take the loose idea you walked in with and cut it down to the smallest version that still demos as something real. One clear feature that works beats five that half-work.

Be honest about what you can leave out. The parts a judge won’t see can be hardcoded, stubbed, or skipped for now. If a feature isn’t part of the story you’ll tell in the demo, it’s a fair candidate to set aside. Cutting hard in the first hour is what buys you a finish at the end.

Manage Your Hackathon Time Well

A hackathon is a time-boxed event, and time is the resource teams tend to manage worst. Whether it’s 24, 36, or 48 hours, the shape is the same: build, then polish, then get ready to present. The mistake is coding right up to the buzzer with nothing left for the demo.

Reserve real time at the end for the presentation. A rough rule: leave the last stretch for polishing the happy path and rehearsing the pitch, not for adding features. Whatever isn’t done by then isn’t getting done, and that’s okay.

AI moves the clock in both directions. It can clear away the setup and boilerplate that used to eat a beginner’s first two months, which is exactly why it fits a time-boxed event. But leaning on it to generate something the team doesn’t understand can cost more time than it saves when the thing breaks and nobody knows why. Use it to move fast on the known, not to paper over the parts that matter.

Build For The Demo, Not Just For Function

Judges score what they see, and that changes how you build. The parts of the project a judge will watch live need to work cleanly. The parts they won’t see can be held together with duct tape.

Define your clear “happy path”: the exact sequence you’ll walk through in the demo, where every step is one you’ve tested and know won’t break. Then protect it. And because live demos fail at the least convenient moment, record a backup and grab screenshots. A team that can fall back to a recording when the wifi dies looks prepared while a team frozen at a spinning loader does not.

Perfect Your Elevator Pitch

The demo is where a lot of hackathons are decided, and it’s the part that a lot of teams practice the least. A great build with a confusing pitch gives ground to a good build explained well.

A structure judges respond to: Present the problem, what you built, a live demo of it working, and then talk about where it goes next. Keep it short. Most judging slots are only a few minutes, so every sentence has to earn its place. Open with the problem so the judge knows why the thing exists, then show it doing the thing.

On a team, decide who says what before you’re standing in front of a judge. A solo builder does it all, which is a good reason to rehearse it out loud at least once. And be honest about AI-assisted work. Using AI is a normal part of how software gets built now, and it’s allowed.

How to Handle the Submission Mechanics

It’s a real heartbreak to build something great and then forget to submit it correctly. Submission requirements aren’t optional, and missing one can disqualify a team no matter how good the project is.

Typically that means a submission on the event platform, a README that explains what the project is and how to run it, and a demo video. Hackathons can differ, but you can read MLH’s official rules for submission in our policy guide.

What “Winning” a Hackathon Really Means

Placing is one outcome. It isn’t the only one, and treating it as the only one is how people leave a great weekend feeling like they lost.

The project is yours to keep and keep building. The people you met are a network you didn’t have on Friday. You almost certainly learned something you couldn’t do the week before. And within the MLH ecosystem, participation feeds into a season-long standings system that rewards showing up and building over time.

The clearest through-line across every hackathon: the builders who get the most out of it are the ones who finish something, tell its story, and come back. Placing is great when it happens. It’s just never the only thing you walk away with. What happens to the project after the event, turning it into something bigger or into a job, is its own guide.