How to Win Hackathons: Lessons from 3 Wins in 2 Months

Between October and November 2022, I won two major hackathon prizes back to back. Best Google Cloud at HackHarvard with ReAlive, Best AI/ML at HackUMass with Meta-Identity. Then I mentored at HackGT9 and watched dozens of teams make the same mistakes I used to make. Put it all together and I think I've figured out some patterns.

This isn't a "top 10 tips" listicle. This is what actually worked, from someone who just had the best hackathon run of his life.

Pick the Right Team Before the Right Idea

I see teams form around ideas all the time. Someone pitches a concept and strangers group up. That's backwards. The team matters more than the idea. You want people you've worked with before, or at least people whose skills you trust.

For both HackHarvard and HackUMass, I worked with the same core group. We knew each other's strengths. We knew who could handle the frontend, who'd manage the ML pipeline, who was good at presenting. That familiarity saved us hours of coordination overhead.

If you don't have a regular team, go to smaller hackathons first and find your people. Treat early hackathons as team tryouts, not competitions.

Scope Ruthlessly, Then Scope Down More

The number one killer of hackathon projects is ambition. You have 24 to 36 hours. That's it. I've seen brilliant ideas die because teams tried to build a full platform when they should have built a single feature.

Our rule: define the demo first, then build only what the demo needs. For Meta-Identity, the demo was "upload a photo and voice clip, get a video of your digital clone speaking." Everything we built served that one flow. No user accounts. No database. No settings page. Just the core experience.

If a feature doesn't show up in the demo, it doesn't exist. Sorry.

Allocate Time for the Demo Like It's a Deliverable

At HackHarvard, we reserved the last four hours for demo prep. People thought we were crazy. We spent that time recording a clean demo video, polishing the UI, and rehearsing our pitch. Three other teams had technically stronger projects but stumbled during presentations.

The demo is the product. Judges see your project for maybe five minutes. They don't read your code. They don't check your architecture. They watch your demo and listen to your pitch. That's it.

Write a script for your presentation. Practice it twice. Have a backup demo video in case the live demo breaks, because live demos break constantly.

Technical Choices That Save You Hours

Some practical advice on tech:

Use pretrained models. HuggingFace is your best friend. Don't train anything from scratch at a hackathon. Fine-tune if you must, but prefer zero-shot or few-shot approaches. For Meta-Identity, we used pretrained voice cloning and talking head models. We didn't train a single weight.

Have templates ready. I keep a starter repo with a Flask backend, a basic React frontend, and Docker configs. When the hackathon starts, I clone it and start building on top. That saves the first two hours of setup.

Use free cloud credits aggressively. Most major hackathons offer Google Cloud, AWS, or Azure credits. Use them. We ran our GPU inference on Google Cloud at HackHarvard and it was the difference between a demo that worked and one that crashed.

Storytelling Wins Prizes

Look, here's the thing nobody tells you. Judges are usually industry professionals or academics who've been watching demos for hours. They're tired. They've seen fifteen "we used GPT-3 to do X" projects. You need to make them feel something.

Tell a story. Why does this matter? Who does it help? What's the moment that made you build this? For ReAlive, we framed it as preserving memories of loved ones. That emotional hook landed harder than any technical explanation.

At HackUMass, we cloned a judge's voice live on stage. The room went silent, then exploded. That moment won us the prize more than any slide ever could.

The Real Secret

Honestly, the real secret to winning hackathons is just doing a lot of them. Every hackathon teaches you something. You learn to estimate time better. You learn what judges care about. You learn which technical bets pay off and which ones waste your night.

Go to hackathons. Build things. Fail sometimes. Keep showing up. The wins will come.

And if you're at a hackathon right now reading this at 3am while your code refuses to compile, take a breath. Eat something that isn't Red Bull. You've got this.