How to Record a Winning Hackathon Demo Video

Record a hackathon demo video that survives judging: script the two-minute story, pre-record risky steps, and export a file that plays anywhere.

How to Record a Winning Hackathon Demo Video

You built something in 48 hours on four hours of sleep, and now the entire project gets judged on a two-minute video. That video is not a formality — for most online hackathons it is the only thing judges actually see. Half the submissions are shaky screen captures with no audio, so a clear recording puts you ahead of the field before anyone looks at your code.

Here’s how to record a demo video that does your project justice, even with an hour left on the clock.

1. Read the Submission Rules First

Before you record anything, check the rules page for hard requirements. Most hackathons specify:

  • Maximum length — usually two or three minutes, and judges genuinely stop watching at the limit
  • Format — MP4 is accepted everywhere; some platforms want a YouTube or Vimeo link instead of a file
  • Public visibility — an unlisted link that requires sign-in will disqualify you
  • Content requirements — some events require you to show the app running, not just slides

Set your export settings to match before your first take. Re-exporting at 3 a.m. because the file exceeds an upload cap is a bad way to spend your last hour.

2. Script the Two Minutes

Two minutes is roughly 300 spoken words. That is not enough room to improvise, so write the beats down first:

  • 0:00–0:15 — the problem. One sentence a stranger understands. No team introductions, no “we’re excited to present.”
  • 0:15–0:30 — the solution. What you built and who it’s for.
  • 0:30–1:30 — the demo. The actual product, doing the actual thing.
  • 1:30–1:50 — what’s under the hood. The technically interesting decision, briefly.
  • 1:50–2:00 — what’s next. One line on where it goes.

The single most common mistake is spending 45 seconds on background context and then rushing the demo. Judges are scoring what you built. Get to the screen fast.

3. Prepare the Demo State Before You Hit Record

Nothing wastes a take like typing a login form or waiting on a cold start. Set the stage first:

  • Sign in and put the app in the exact state your first shot needs
  • Seed realistic data — “test test test” and asdf@asdf.com make a project look unfinished
  • Close every unrelated tab, and clear notifications and Do Not Disturb
  • Bump your browser and editor font size; judges may watch on a laptop or a phone
  • Warm up any slow endpoint so the first request isn’t the cold one

Use window capture rather than full-screen capture so your dock, wallpaper, and other monitors stay out of frame.

4. Record in Segments, Not One Perfect Take

A single flawless run-through is a fantasy at hour 46. Record in short segments — one per section of your script — and stitch them together. When a segment goes wrong, you redo thirty seconds instead of two minutes.

Segments also let you skip real waiting time. Record the “submit” click, stop, wait for the job to finish, then start again on the result screen. Cut the ninety-second processing wait entirely, and the demo reads as fast rather than dishonest.

If a step is genuinely flaky — a rate-limited API, an unreliable deploy — record it early while it works and keep that clip safe.

5. Narrate It Yourself

Record microphone audio and talk over the demo. Judges consistently rate narrated demos higher than silent screen captures with background music, because they can follow the intent behind each click.

A few things that make narration land:

  • Record in the quietest room you can find, not the venue floor
  • Speak slightly slower than feels natural — you’re excited and sleep-deprived
  • Say what you’re about to do before you click it
  • If English isn’t your first language, script your lines and read them; that’s completely fine

If your voice is wrecked from a long night, record it anyway. Imperfect narration beats no narration.

6. Edit for Clarity, Not Style

Keep post-production to what actually helps a judge:

  • Trim dead air at the start and end of every segment
  • Zoom into small UI elements — buttons, form fields, log output — so they’re readable on a small screen
  • Text overlays to label the section, or to name a technology you’re showing
  • Webcam PIP for the intro and outro only, so your face is on screen without covering the product
  • Captions, if the platform supports them, since many judges watch muted on a first pass

Skip the animated intro, the drone shot of your city, and the music bed that fights your narration. None of it earns points.

7. Export and Check the Upload

Export at 1080p, 30 FPS, MP4 with H.264. That combination plays on every judging platform and browser without transcoding surprises.

Before you call it done:

  • Watch the whole file back once, start to finish, with sound
  • Check that no credentials, private tokens, or personal messages appear on screen
  • Confirm the file uploads and plays from the submission page itself, not just locally
  • Verify the link is public and doesn’t require an account

Submission Checklist

  • Length matches the rules with a few seconds to spare
  • Problem stated in the first fifteen seconds
  • Live product on screen for at least half the runtime
  • Demo data looks realistic
  • Narration recorded and audible
  • Key interactions zoomed for small screens
  • No secrets or notifications visible
  • Exported as 1080p MP4 and verified after upload

Ship It

The teams that win hackathons are rarely the ones with the most code. They’re the ones whose demo makes the idea obvious in ninety seconds. Script it, record it in pieces, narrate it, and export it early enough to watch it back once.

Then go get some sleep.