To make a hackathon demo video in an hour, spend the first fifteen minutes on a 300 to 400 word script, record the working product for fifteen, make a short drawn explanation of the problem and the architecture for fifteen, and use the last fifteen to stitch, caption and upload. Keep it under the limit, which on most Devpost hackathons means three minutes, because judges are not required to watch past it. Open with the problem in one sentence, show the product actually working by the forty second mark, explain how it works in thirty seconds, and end on what you would build next. The recording proves it exists. The drawn part makes it understood.

What judges do with your video

Judges at a big online hackathon may have dozens or hundreds of submissions. They watch the first twenty seconds of each to decide how closely to watch the rest. What they are looking for, roughly in this order:

1. Does it work. Most Devpost rules say the video should show the project functioning on the device or platform it was built for. A slide deck with no running software is the most common reason a good idea scores badly.
2. What problem it solves, and for whom. In one sentence, early.
3. Is it technically interesting. What is hard about it, and how you solved that.
4. Could it go somewhere. What is next, and whether it is realistic.

At the Smart India Hackathon, the stage before the grand finale works differently: teams of six submit through their institution's coordinator (the SPOC), typically an idea presentation in the official template and, in recent editions, a short video. You may not have a working build yet at that stage, so the video carries more of the explanation. Read the current year's guidelines on sih.gov.in rather than last year's, because the format changes.

The structure, by the second

For a three minute limit, aim for two minutes thirty. Uploads get trimmed, intros run long, and finishing early reads as confident.

Two kinds of footage, used for different jobs. The screen recording is evidence: unedited enough that a judge believes it is real. The drawn scenes are explanation: the parts that are hard to show by clicking around, like why the problem matters or how data moves through your system.

Worked example: fleet coordination for warehouse robots

Here is a full script for a Smart India Hackathon style entry. The team built software that lets warehouse robots coordinate their routes without a central server, so one failure does not stop the whole floor. About 380 words, which runs around two and a half minutes at a normal speaking pace.

Problem (drawn). "A mid-sized warehouse runs forty robots. Every one of them takes its route from a single central server. When that server drops, even for a minute, every robot stops where it is, and the orders back up."

Solution (drawn). "We built Swarmlane. Each robot plans its own route and negotiates with the robots near it, so there is no single point that can stop the floor."

Demo (recording). "Here are twelve simulated robots on a warehouse grid. We send twenty pick orders. Watch the two robots heading for the same aisle: they exchange intent, and the second one waits two seconds instead of colliding. Now we kill robot seven. Its neighbours notice the missing heartbeat within a second and its orders are picked up by the robot nearest to each shelf. Throughput dips and recovers. Total orders completed: twenty out of twenty."

How it works (drawn). "Every robot broadcasts its next three grid cells to robots within range. If two claims overlap, the one with the lower battery yields. Orders sit in a shared queue that any robot can claim, and a claim expires if the robot holding it goes quiet. That is the whole protocol: claims, yields and expiry."

What is next (drawn). "Next we want to test on real hardware, starting with four small robots on a taped grid, and measure how the protocol behaves when radio messages drop. Team Swarmlane: Ananya, Rohit, Meera, Kabir, Sana and Dev."

Three things this script does deliberately. The demo includes a failure, because the failure case is the project's whole point. The numbers are specific (twelve robots, twenty orders, two seconds), because vague demos read as staged. And the architecture is described in plain words before any jargon, so the drawn boxes have something to illustrate.

The hour, minute by minute

Minutes 0 to 15: script. Write the five sections above in plain sentences. Read it aloud with a timer. Cut until it fits in two minutes thirty. If you have a teammate free, they write while you set up the recording.

Minutes 15 to 30: record the demo. Use whatever is already on the machine: the built-in screen recorder on macOS or Windows, OBS, or a phone on a stack of books for hardware. Close notifications. Zoom the browser so text is readable on a phone. Record the main path two or three times and keep the cleanest take. Narrate over it live or record the voice separately afterwards; separate is usually cleaner.

Minutes 30 to 45: the drawn scenes. Paste the problem, solution, how-it-works and next-steps sections as one short script and draft them as drawn scenes. Check every label on the architecture scene. Drafted diagrams like to invent a database or an arrow you do not have.

Minutes 45 to 60: stitch, caption, upload. Put the drawn opening, the recording and the drawn closing together in any basic video editor (CapCut, Clipchamp, iMovie and DaVinci Resolve all work). Add captions; judges often watch with the sound off. Upload to YouTube or Vimeo as public or unlisted, whichever the rules require, and open the link in a private browser window to confirm it plays for someone not logged in.

Things that get submissions marked down or disqualified

• Over the length limit. Some hackathons stop watching, some penalise, a few disqualify.
• Private video links. The judge clicks, sees "this video is private", and moves on.
• Mockups shown as working software. If part of the demo is a Figma prototype, say so on screen. Judges who discover it later are not forgiving.
• Code or assets written before the event, where the rules forbid it. Some hackathons check commit history.
• Music you do not have rights to. It can get the upload muted or blocked, sometimes after the deadline.
• Inaudible audio. A laptop microphone in a noisy hall is worse than a generated voice reading your script clearly.

Make it

1. 1

   Write the five-part script with a timer running

   Problem, one-line solution, demo, how it works, what is next. Read it aloud and cut until it fits two minutes thirty.

2. 2

   Record the product working

   One clean take of the main path, including a failure or edge case if that is the interesting part. Readable text, no notifications.

3. 3

   Draft the explanation scenes

   In openCanviz, paste the non-demo sections, choose Keep my wording so the narration matches your script, and pick whiteboard, which suits architecture. Generate the voice or record your own.

4. 4

   Fix the architecture scene

   Compare every box and arrow with what you actually built. Delete anything invented and correct the labels before you export.

5. 5

   Stitch, caption and test the link

   Drawn opening, recording, drawn closing, in any video editor. Upload, then open the link logged out to confirm judges can watch it.

Common questions

Should I use a generated voice or my own? Your own, if you can record somewhere quiet; judges like hearing the team. If the hall is loud or you are short of time, a generated voice reading your exact script is clearer than a rushed recording. You can replace it later.

Do I need to show my face? Rarely. A two second team card with names is plenty. The time is better spent on the demo.

What if the product does not fully work yet? Show the part that works, say plainly what is simulated or hard-coded, and use the drawn scenes to explain the intended design. Honesty about scope scores better than a demo that a judge suspects.

Can I reuse the video after the hackathon? Yes, and it is worth doing. The same structure, longer and with more detail, becomes a portfolio piece or a capstone presentation. See how to make a video explaining your capstone engineering project. For more on narration timing, how to add voiceover to a whiteboard video covers recording and replacing the voice.