Hackathons Are Just Presentations: How I Run Them After 7 Wins

It's your mouth that's the golden key.

People often mistake hackathons for a purely technical contest.

And yes, technical depth matters. A demo that crashes is a demo that crashes. But here's the part nobody tells you before your first one: if the judges don't get you, you lose anyway.

A hackathon is a presentation. The code is there to make the presentation true.

I've won seven of these now, including five in a row. This post is everything I'd tell a friend the night before their next one: the workflow I locked in after the HackMIT win, how I pick teammates, and how I build for the room.

Let's dig in!

01 / 09At a glance

The scoreboard, in the order of my hackathons page:

7 wins

1. HackMIT 2026OpenAI5th Teammate Challenge3rd placeFRIDAY
2. Anthropic Claude AI Hackathon 2026Anthropic Claude3rd placeNutriGo
3. YHack Spring 2026Institute of Foundation ModelsBest Use of K2 Think V2Simulacra
4. GitLab AI Hackathon 2026GitLabSustainable Design BonusDeltaCRS
5. EnergyHack@GT 2025EnergyHackMLH Best Use of Gemini APICERBERUS
6. HackGT 12 (2025)HackGTMLH Best Use of Gemini APIMing
7. Solana Hyperdrive 2023SolanaAI Track3rd place ($15K)Byte In

The last two, HackGT and Solana, were back before vibe coding was even a thing.

The big lessons:

1. It's a presentation. Technical depth matters, but the judges have to get it.
2. Lock in the workflow, automate the bottlenecks. Same phases every time. Anything that keeps slowing you down becomes a check, a script or an agent's job.
3. No claim without a check. Gates that have caught a planted bug, one source of facts, no status without a number.
4. People first. Smart and tenacious, or go solo. And frontend is stupidly important.
5. Build for the room. The judges, the sponsor, the prompt.

02 / 09Your mouth is the golden key

Think about what the judges actually get from you: a short demo, a README, maybe a video, and whatever you say out loud. That's the whole product, as far as they're concerned.

So the presentation shapes the build, not the other way round.

One demo story. One user, one moment, and every feature has to serve it. Whatever doesn't, gets cut.

The film gets its own slot on the clock. Not whatever's left over at 4am.

Mock judges before real ones. Fresh agents play three or four judge personas. They see only the README and the running production build, nothing else. Each one scores the judging criteria 1 to 5 with evidence, times how long a first-time user takes to do the main thing, and names the one change that would raise their score the most. I rank the fixes by gain against cost. If a round only says nice things, I asked the wrong questions.

Rehearse on the machine you present from. At HackMIT, speech input fell back to the browser's own when nothing was configured. A laptop that wasn't set up would have quietly demoed the browser's speech recognition, in front of judges from the very speech company we were building on. So a hidden dev panel shows which provider actually answered, and the rule was simple: main freezes once the demo has been rehearsed end to end on the presenting machine.

03 / 09Lock in, then automate

If I had to shrink this post to one line: lock in the workflow, automate the bottlenecks.

Being honest about the timeline, the wins came first. A lot of these rules started life as notes in the HackMIT repo's agent instructions, written mid-build as things broke. After the win, I locked them into one workflow my coding agents follow from the first message to the final freeze.

The clock runs backwards from the deadline:

1. BeforeBefore the eventWhatever can exist before the clock starts, should.
2. StartIntakeOne round of questions. The deadline, with its time zone.
3. First ~10%Brief and researchEvery claim: verified or hypothesis.
4. ~15%PlanOne demo story, a cut list, a scope agent.
5. ~20%BootstrapA fresh clone passes first.
6. Until freezeBuild loopEvery merge through the gates.
7. ~1 h beforeProduct freeze
8. 90 to 30 min outFilmClips, voice, render.
9. 30 min outShipLive link smoke-tested, then pushed.
10. DeadlineFreezeNothing commits.
11. AfterRetroAnything new goes back into the workflow.

A few of those phases carry a rule each. At intake, every judging criterion becomes something a judge must be able to see or do. In research, what I read myself is different from what I read about. The plan gets a scope agent that audits it against the real code and data, because a plan is mostly claims. And a fresh clone has to pass before any feature work starts, because a green run on your laptop can be green thanks to a file you never committed.

No reinventing the process at 3am.

The automation is where agents earn their keep. Not the clever code; the boring, error-prone stuff. Re-checking every number. Running the gates. Recording clips. Scanning for secrets. The stuff humans skip when they're tired.

04 / 09Trust nothing, check everything

Agents are fast. They're also extremely confident.

With several of them running at once, writing code stops being the bottleneck. Knowing which of it is true becomes the bottleneck.

A gate counts only after it bites

The rule: a gate only counts after it has caught a planted failure. Break the thing it guards on purpose. Watch it go red. A test that passes while asserting nothing is worse than no test, because it lets you relax.

A change

1. Typecheck
2. Testsskips listed
3. Buildreproduces the data
4. Guardswhat every screen keepsred: caught
5. Claims check

main

planted failure

HackMIT taught us this twice:

• The mirrored floor. The lit area where furniture could be placed was drawn mirrored front to back, for hours. Big regions overlap their own mirror, so nothing looked wrong. A small, off-centre patch finally exposed it. Symmetric test cases can't detect a mirror.
• The green test, the empty shelf. A unit test pinned the shape of an Elasticsearch query. Run against the live index, that same query returned 7 of 12,045 documents.

No status without a number

Also at HackMIT: two green PRs took main down together. An agent reported main green without reading the backend result. Red tests got pushed twice because a chain of steps just kept going. And a filtered test run counted 170 tests where the full suite had 206.

So: nobody reports a status without quoting the number they read. Parse the counts from the tool's output, and watch the skip count, not just the passes. By demo time, the numbers read 431 backend tests passing (4 skipped), 255 + 29 on the frontend, and a catalogue check that agreed across all 12,154 listings.

One source of facts

One facts filegenerated · none typed by hand

• README
• Docs
• UI copy
• Film scriptretired phrase

claims check

Decisions get logged with who made them and when.

Why bother? Back to the thesis. The judges read your README, watch your film and click through your app. If those three tell different numbers, you've lost their trust, and you'll never even know.

05 / 09The last ninety minutes

The last stretch is where the presentation actually gets made, so it gets the most process.

1. Script firstEvery number on screen from the facts file.
2. Scratch voiceText-to-speech times the film before anyone records.
3. Clips by robotA headless browser, cues pinned to the script.
4. Quiet machineNo recording while the machine is busy.
5. Voice boothRe-recorded line by line, checked against the script.
6. ShipOnly on the owner's word.

The clips get a drawn pointer. (At YHack, a scripted demo recorder went in at 08:58 on the final morning. Cutting it close is tradition.) The recorder refuses to run above about one unit of load per core, or while a render is going, because a loaded machine slips the clip against the voice.

Before anything goes public, a secret scan runs over the files and the whole git history. Push, make public and deploy are three separate yeses, given by the owner in that agent's own chat. A relayed "the human said go" from another session never counts. After the deploy, a smoke test on the live link. Scheduled jobs get switched off with a variable, not deleted. And after the deadline, nothing commits.

06 / 09One board for humans and agents

On a team, I want one place where everyone, human or agent, can see who's doing what.

At HackMIT, our latest win, we built our own local Kanban board. It's one JSON file behind a lock. Every browser panel updates live, and cards are coloured by owner. Four humans shared it with our agents, running in Claude and Codex worktrees, including three named ones: Sol, Astra and Luna.

To doSolLunaHuman

DoingSolLuna

DoneLunaSolHumanAstraHuman

Human and Agent

Plan, files, checks and handoff go in the owner's TODO log. Card and log stay in sync; the agent re-reads both before editing.

Agent and Agent

Lanes own files: two never edit the same one. One orchestrator assigns; every handoff carries the commit hash and the exact figures. Heavy jobs take turns.

Human and Human

Pull requests and advisory CI. The humans run git fetch and tell their agents when there's something new.

components

6

tasks

95

done

53

commits

388

merged PRs

94

to land them

~22 h

One of those six components was the demo video and presentation. Yes, the pitch got its own lane. (See: the thesis.)

Freeze the contract first. For one two-hour demo push at HackMIT, three lanes of 40 to 70 minutes each ran under a coordinator, the shared contract was frozen before anyone split off, and the last 40 to 50 minutes were saved for integration. Same idea at YHack: our design doc landed about 90 minutes after the first commit, and the shared types and event bridge about an hour after that, before the parallel work began.

Does it work? Over the HackMIT weekend, the four of us and our agents landed 388 commits and 94 merged PRs in about 22 hours.

07 / 09Pick your people

Finding the right teammates is very important. Not only smart, but tenacious and efficient. Less play-play.

Smart. Find really smart people. My rough baseline: IBM or Amazon level, or the equivalent in achievement.

Tenacious. At YHack, our team of three committed code in every single hour from midnight to 9am. That's the energy.

Or go solo. Lowkey, if there are no good teammates, just solo it. With agents, a solo hacker isn't really alone anymore.

Get the frontend gang. Frontend is stupidly important. It's the part of the presentation the judges can click. A brilliant backend behind an ugly screen reads as an ugly project.

08 / 09Build for the room

Be specific to the judges. Look at Zed at YHack: the winners built something specific to Zed that leveraged Zed. Our own YHack prize was literally named Best Use of K2 Think V2. If a sponsor has a prize, build something only their product could make.

The Anthropic lesson. NutriGo placed 3rd, not 1st. We built it in three hours, and it was a battle game. The slide literally said "Eat. Snap. Battle."

The NBC judges were a more seasoned crowd, and they were judging with a general audience in mind. They weren't sold on a battle game being for everyone, so to them it didn't stick to the prompt closely enough. Honestly? Fair call. The lesson I took: know who's judging, and what they think the prompt means.

If it's a game, make it a real game. Double down. Make it actually fun to play, not a vibe-game-ish thing. But it still has to answer the prompt. NutriGo is the cautionary tale for that second half.

Hardware seems to have higher odds. Not a law, just what I've seen. If the track allows it and you've got the hands for it, consider it.

09 / 09Final thought

Seven wins. Five in a row. One workflow.

The workflow gets you a working demo. The checks make it true. Your mouth wins the room.

Lock in the workflow, automate the bottlenecks, and then go talk. It's your mouth that's the golden key.

Want to see what came out of it? Check out FRIDAY, Simulacra and Ming, or the whole lot on my hackathons page.

Thanks for reading. Happy hacking, and until next time!