How To Win Hackathons

Its a lot easier than you might think!

I’ve won maybe seven or eight hackathons. Close to a 90% win rate. About forty thousand in total prizes, split with teammates. I won TechCrunch Disrupt. I’ve won with AI, and I’ve won without it.

Last month I went to an AI robotics hackathon in San Francisco and won the grand prize! I’m going to walk you through exactly how I did it, and how you can win these yourself.

I hadn’t been to a hackathon since joining Meta. You kind of stop going to meetups and hackathons when you’re working full-time. You lose that fire. But I took the train into the city, walked into the venue, and immediately felt it come back. One flat open space, people everywhere, my friend Juni already there. We’ve done a bunch of these together and we have a 100% win rate as a team. Kids were already hooked into robots, controlling them before the event even started. I was getting fired up.

If you would prefer to watch the vlog version of this newsletter check it out here!

Hackathons Are Marketing

The best way to win hackathons is recognizing what a hackathon actually is. In my opinion, a hackathon is just marketing. The sponsors are paying to be there. They want developers using their tools, creating demos, generating content that makes them look good. The organizers want a story. If you understand that, you can work backwards from it.

Look at Anthropic’s last hackathon. A bunch of non-engineers won. People who’d never written code used Claude Code to build things and took home prizes. I’m not taking anything away from those hackers. But if I was organizing that event, I know exactly what story I’d want to tell. “Even non-engineers can build with Claude Code.” That’s a much bigger audience than just developers.

Every hackathon I’ve been to works this way. The sponsors want to see their tools used well. The judges want a compelling demo. The organizers want a narrative they can promote. If you understand who wants what, you build for the audience instead of building for yourself.

This particular hackathon was an AI robotics hackathon. They had robot arms, a robot dog, and claws you could control. The main prize was for the best robotics hack, but there were also a bunch of sponsor tracks on top of that. So the first thing I did was walk the sponsor tables and start figuring out how to make them all look good.

Talk To Sponsors, Stack The Tracks

Most teams pick one sponsor track and build for it. But you can qualify for more than one at a time, and most people don’t think to do this.

I started looking at the tracks. The main robotics prize was obvious. Everyone would target that. But then there was Smallest AI doing phone agents, Toolhouse doing agents as a service, Cyberware for the robotics control, and Jade Hosting for deployment. Most teams would pick one. I wanted to hit as many as possible. The more sponsors you use, the more chances you have of winning a specific sponsor prize.

So Juni and I split up. I researched the sponsor tools and started figuring out how they could all connect into a single product. He went deep on the Cyberware robotics stuff. And then we started talking to the sponsors.

This is probably the most underrated thing you can do at a hackathon. Build rapport with the sponsors. Not too often, but enough that they know you, they know you’re actually hacking, they know you’re using their stuff. They’re also great resources for their own products. They’ll give you hints on what they’re looking for. You pitch ideas, gauge their reaction. If they light up, you’re on the right track. If they give you a flat “oh yeah, that’s cool,” pivot.

I learned this years ago at TechCrunch Disrupt. The Esri booth had this incredible demo. A pulsing, animated map with city data flowing in real time, built on their JavaScript framework. I asked if they had the same thing on iOS. They said no. Said they’d been trying to figure it out but hadn’t cracked it yet.

I looked at the guy and said, “If we build that for you tonight, do we win your prize?”

He stared at me for a second. “Yeah. You guys pull that off, it’s yours.”

I went back to my team and told them to scrap everything. Six hours of work, gone. We pivoted the entire project around that single conversation. And we won. The code was a mess. Half the features were not fully working but that didn’t matter. During the announcement, the Esri sponsor basically said it himself. He gave it to us because we built the thing he wanted to exist.

The sponsors are the judges. They’re in the room. Use them.

Back at the robotics hackathon, we landed on a project that hit all four tracks. A voice-controlled robot butler called Alfred. You call a phone number (Smallest AI), that connects to a voice agent, which routes through an agent framework (Toolhouse), and that controls the actual robots (Cyberware). We hosted the MCP server through Jade. One project, four sponsor categories. Now we needed to build it.

Team

Later in the day my friend Kevin joined us too. He was actually my manager for the past five years at Meta. We’ve jumped from multiple projects and teams together. Reels, Meta AI, Threads. I’ve worked with him long enough to know exactly what he’s good at. And that matters more than most people realize.

A lot of people show up to hackathons solo and join a random team. You burn the first few hours just figuring out how strangers communicate. Go with people you know. People whose strengths you already trust.

Every hackathon team needs at least three roles. Not three people necessarily, but three roles covered.

You need someone to PM and present. That’s the person talking to sponsors, locking down the product direction, keeping the clock in mind. If your hackathon is seven hours long, you cannot spend an hour debating ideas. Someone has to take the inputs, make a call, and get people moving. That was me.

You need a deep diver. Someone who can disappear into the hardest technical problem for four hours and come out with something that works. That was Juni. He went deep on the robotic arm movement code and didn’t surface until it was done.

And you need a generalist. Someone who wires everything together, handles integrations, fills gaps. That was Kevin. Toolhouse agent routing, the robot dog, all the glue work.

We had our roles, we had our plan, and we started building.

Build For The Demo

You’re not building a product. You’re not even building a prototype. You’re building a demo.

This is where most teams lose. They spend 95% of their time building and 5% on the pitch. That ratio should be reversed. The happy path needs to work. The hardest thing you claim to do needs to actually function. Everything else can be mocked, static, held together with duct tape. Rough edges are fine. But the core thing has to be real.

We scoped ruthlessly. No edge cases. No error handling beyond “try again.” One happy path, polished until it looked intentional. Every feature we cut was a feature that couldn’t break during the demo.

With about two hours left, we started making the demo video. Most teams were still deep in code. Always have a video ready if the rules allow it. Live demos are usually the best option, but things can go wrong. And this time they did. The organizers announced everyone had to show pre-recorded videos because of technical difficulties with the robots.

Half the teams scrambled, but we were ready for it.

Presentation

Lead with the problem your hack solves and tell a good story. The tech stack matters, but it’s not your opening line. Start with what the thing does and why it’s cool. Then walk them through how you built it, making sure the sponsor tools are front and center. They want to hear their product name on stage. The feeding arm was the crowd favorite. Alfred tells you to get ready, activates the arm, says “just say stop whenever you need.” People laughed. That’s what sticks. The technical details land better after the audience already cares.

Show the hardest thing working. If you claim your hack does something impressive, that thing needs to actually function on stage. Everything else can be rough. But the one wow moment has to be real.

When judges ask about features you didn’t build, frame them as design choices, not gaps. “We scoped that out intentionally to focus on the core experience” sounds a lot better than “we ran out of time.” Missing features become roadmap items. Limitations become deliberate tradeoffs. You’re not lying. You’re presenting like someone who made intentional decisions, because you did.

The team with the best code almost never wins. The team with the best demo does.

We won. Grand prize. Alfred Robot Butler.

Go To Hackathons

After the awards, I ended up back at the robot table with a screwdriver, unscrewing a panel so I could plug in a USB cable. And I was having so much fun just doing that. Tinkering with something physical, something AI can’t autocomplete for me. It reminded me why I got into building things in the first place.

Go to hackathons. Especially right now with AI. Before, they were stressful. Now it’s basically vibe coding all day with zero thought about maintenance. You just need to get it to work. That’s the perfect use case for vibe coding. No production code, no tech debt, just “does it work for three minutes on stage?” It’s genuinely fun.

And if you want to win: remember that hackathons are marketing. Talk to sponsors. Stack the tracks. Go with people you trust. Build for the demo, not the product. And present like the demo is the product.

Keep the hacker sprit alive!