Articles
How to make a hackathon demo video judges can trust
A shot-by-shot template for a short AI demo video, and the checklist that lets judges try your project themselves.
By Starfield LabsPublished

A good hackathon demo video is short, shows your project running on real input, and makes the AI's job obvious within the first minute. Plan it as a sequence of shots before you record, keep the key moment uncut, and pair the video with clear access details so judges can check it for themselves. Below is a template you can copy.
What makes an AI demo video convincing?
Assume a judge may watch your video quickly, among many others. Make sure they can see three things:
- The problem, fast. Who has it and why it matters, in one or two sentences.
- The model doing real work. A real input goes in, the model processes it, and a useful output comes out, on screen, without a cut in the middle.
- Honesty. What works, what does not yet, and what is mocked, if anything.
In our view, a plain screen recording that clearly runs live is more convincing than a polished video with output that might have been pasted in.
What is the shot-by-shot template?
A good target is two to three minutes, unless the event sets a different length. Adjust the timings to fit.
| # | Shot | Time | What to show and say |
|---|---|---|---|
| 1 | Hook | 0:00 to 0:10 | Project name and one sentence: what it does and for whom |
| 2 | Problem | 0:10 to 0:30 | The pain, shown with a real example: the messy document, the long thread, the confusing form |
| 3 | Input | 0:30 to 0:45 | Put that real example into your project, on screen |
| 4 | Model at work | 0:45 to 1:30 | One continuous take: the request runs and the output appears. Narrate what the model is doing |
| 5 | Result | 1:30 to 1:50 | Zoom in on the output and point out why it is useful |
| 6 | Second example | 1:50 to 2:15 | A different input, ideally a harder one, to show it is not a one-off |
| 7 | How it works | 2:15 to 2:35 | One simple diagram: input, model, tools or data, output |
| 8 | Limits and next steps | 2:35 to 2:50 | One honest limit and what you would build next |
| 9 | Close | 2:50 to 3:00 | Name, team, and where to try it |
If a step takes a while to respond, keep the wait in but say so, or show a timer. For example: "it is reading the whole document, so this step takes a moment." If you do cut a wait, say on screen that you cut it.
How do you record it without wasting hours?
- Write the script first. Bullet points per shot are enough. Read it aloud once to check the timing.
- Prepare your inputs. Have the real examples open and ready. Clear old test data, notifications and open tabs.
- Record in sections. Record each shot separately, except shot 4, which should be one take.
- Use a plain screen recorder and a decent microphone. Put clear audio ahead of fancy visuals.
- Make text readable. Increase browser zoom or font size so the output is readable on a small screen.
- Add captions or on-screen labels, in case someone watches without sound.
- Export early. Upload a draft well before the deadline, check it plays, then improve it if you have time.
Give yourself at least an hour for recording and uploading, and more if you can.
What access should judges have?
A video shows the project. Access lets judges confirm it. Here is a checklist you can adapt for your submission description:
- A working link to the live project, tested in a private browser window
- Test login details if a login is needed, or a note that none is required
- Sample inputs judges can use, or a note that any input of a given kind works
- A link to your code on a code host such as GitHub, with a short README: what it does and how to run it
- Known limits, such as which inputs fail or which features are mocked
- How long the live link will stay up after judging
Never put API keys or passwords in a public repo or a video. If judges need access to something private, follow the event's instructions for sharing it. Read the event's rules for what the submission must include, and match your description to them.
What are the common mistakes?
- Opening with a long intro, team photos or slides before anything runs
- Cutting away at the moment the model produces output
- Showing only a perfect, prepared example
- Text too small to read
- Music louder than the voice
- Going over the length the event asks for
- A broken or expired live link when judges try it
Watch your final video once at normal speed, as a judge would. If you cannot tell what the AI did by the one-minute mark, rework shots 3 and 4.
Before you submit, ask someone outside your team to watch it once and tell you, in one sentence, what the project does. If their sentence matches yours, the video is doing its job.
Where to go next
Copy the shot table into your team's notes before the event, and fill it in as you build. When you are ready to put it into practice, find an event at starfieldlabs.ai/events. For help building the project itself, the guides at starfieldlabs.ai/tutorials cover the basics.