At a hackathon in Lisbon a couple years back, I watched a team of three demolish a field of about 40 teams with what was, technically, a pretty boring app. A to-do list with reminders. Meanwhile, two seats over, four genuinely brilliant engineers had built a distributed system with a custom scheduling algorithm that, in another context, I'd have wanted to read a paper about. Guess who won? The to-do list people. And it wasn't close.

I've judged or attended well over a hundred of these things, and that scene plays out almost every single time. The best coder in the room rarely wins. So if you've been avoiding hackathons because you don't think your chops are sharp enough, I've got news for you: chops were never the bottleneck.

Judges Reward What They Can Understand in Four Minutes

Here's the thing nobody tells you when you're starting out. A hackathon judge has, on average, somewhere between three and five minutes per team, and they're often watching 20 to 30 demos back to back. By team 15 they're tired, slightly overcaffeinated, and pattern-matching hard. Whatever you built has to land in the time it takes to microwave leftovers.

That distributed-system team in Lisbon? They spent their four minutes apologizing for what wasn't finished and explaining the architecture on a whiteboard. The judges nodded politely and understood maybe 30% of it. The to-do list team opened the app, added a task, and a phone on the table buzzed with a reminder. Everyone in the room got it instantly. That legibility is worth more than any amount of technical elegance.

So my first piece of advice is almost insultingly simple: build something a non-engineer can understand without you talking. If your demo requires narration to make sense, you've already lost points you'll never get back.

Scope Down Until It Hurts, Then Scope Down Again

The most common way I see strong coders lose is ambition. They pick a problem worthy of a startup and try to compress it into 36 hours. By Sunday morning they've got an impressive backend and absolutely nothing to show on screen.

The counterintuitive part: the teams that win usually build less, not more. They pick one slice of a problem and make that one slice genuinely delightful. A polished thing that does 10% of the dream beats a half-broken thing that gestures at 100% of it.

Practically, I'd recommend this split for a weekend hackathon:

  • First third: argue about and lock the scope. Write the demo script before you write code. Literally the sentences you'll say.
  • Middle third: build only what that script needs. Nothing else. No auth flow nobody will see, no settings page, no dark mode.
  • Final third: stop building. Polish the demo, rehearse it, and fix the one path you'll actually walk through on stage.

That last third is sacred. The teams that are still committing code 20 minutes before judging are almost never the teams holding the trophy.

The Demo Is the Product

I know how that sounds. But in the closed universe of a hackathon, the demo really is the entire deliverable. Nobody installs your repo. Nobody reads your code. The judges experience your weekend through a four-minute window, and how you frame that window decides everything.

A few things I've seen separate winners from also-rans:

  • Open with the problem, in human terms. One or two sentences about a real person with a real frustration. Skip the market-size slide.
  • Show, don't describe. Get to a working screen within 30 seconds. Every second you spend on context is a second the judge spends drifting.
  • Have one wow moment and aim everything at it. The buzz of that reminder phone was the whole pitch. Find your version of the buzz.
  • Pre-record a backup. Wifi dies, APIs rate-limit you, laptops sleep at the worst moment. A short screen recording on standby has saved more demos than I can count.

And rehearse out loud. Not in your head — out loud, with a timer, ideally to someone who'll tell you when you're rambling. The difference between a team that has run their demo five times and one that's winging it is visible from across the room.

Pick the Right Room in the First Place

One underrated move: choose events where your strengths actually count. Some hackathons reward raw engineering, sure. But plenty are judged on design, social impact, or how well you fit a sponsor's theme — categories where a thoughtful generalist can run circles around a coding savant who ignored the prompt.

This is honestly where a tool like Droppa earns its keep. Instead of stumbling into whatever event your group chat mentions, you can scan what's actually coming up, read the judging criteria, and pick the ones that play to what you're good at. I'd rather enter three well-chosen hackathons a year than ten random ones. You can find events on Droppa and filter for the format that suits you before you ever commit a weekend.

What to Do This Weekend

If you take one thing from this, make it this: your next hackathon project should be something you can demo, end to end, by Saturday night — leaving all of Sunday for polish and rehearsal. Write the four sentences you'll say to the judges first. Build backwards from those sentences. Cut everything that doesn't serve them.

You don't need to be the best coder in the room. You need to be the team the judges still remember at team number 25. That's a skill, it's learnable, and it has almost nothing to do with how clever your code is.