A Devpost submission video judges actually watch is under three minutes, shows the project working within the first thirty seconds, and is organised around the hackathon's own judging criteria, so each judge can find the answer to each row of their scoresheet without hunting. Many Devpost rules say judges are not required to watch past three minutes, and many run a pass or fail check first: does the project fit the theme and use the required tools? So name the sponsor's API on screen early, open on a first frame that already explains the project, give each criterion its own section, and make sure the video, the written story and the gallery images tell the same story.

What a judge sees before pressing play

Your Devpost project page is the judge's first impression, and the video sits at the top of it. Before anyone watches, they see:

• The video thumbnail. On YouTube this is a frame chosen automatically unless you upload your own. An auto-picked frame of your face mid-word, or a blurry desktop, is a poor first impression. A title card with the project name and one sentence is better.
• The tagline. One line under the project name.
• The written story. Devpost's default template prompts you with headings such as Inspiration, What it does, How we built it, Challenges we ran into, Accomplishments that we're proud of, What we learned, and What's next.
• Built with tags, the gallery, and the try-it-out links.

Judges cross-check. If the video says one thing and the story another, they notice. The simplest fix is to write the video script first and then paste the same sentences into the matching story sections, expanded with detail.

How Devpost hackathons are usually judged

Each hackathon writes its own rules, so read yours. But a large share of sponsored online hackathons on Devpost use a structure very close to this:

Stage one, pass or fail. Judges check a baseline of viability: the project reasonably fits the theme and reasonably applies the APIs or SDKs the hackathon is built around. A good project that does not visibly use the sponsor's tool can stop here.

Stage two, scored criteria. Projects that pass are scored on a short list of criteria, often equally weighted. Common ones:

Read your rubric and swap in its exact criteria. Then, when you write the script, label each paragraph with the criterion it answers. Any criterion with no paragraph is a score you are leaving to chance.

The other rules that commonly appear in Devpost video requirements, and that cost submissions points or eligibility:

• The video should show the project functioning on the device or platform it was built for, not a slideshow.
• It must be uploaded to a public platform the rules name, often YouTube, Vimeo, Facebook Video or Youku, and be publicly visible.
• It should not include copyrighted music, third-party trademarks or other material you do not have permission to use.
• Upload early. Devpost's own help pages warn that video processing can take from a few minutes to several hours.

The structure, one section per criterion

For a three minute limit, aim for two minutes forty. The last twenty seconds are your margin for a slow intro or a trimmed upload.

Put the sponsor's technology in two places: visible in the demo (their logo in the UI, their console, the API call in a log) and labelled in the architecture scene. Stage one judges should not have to read your README to find it.

Worked example: live captions for station announcements

Here is a full script of about 280 words for an imagined accessibility hackathon entry. The app, Platform Pal, listens to station announcements through a phone's microphone and turns them into live captions and vibration alerts, so deaf and hard-of-hearing passengers do not miss a platform change. It assumes the hackathon requires a particular speech-to-text API, called "the sponsor's speech API" here; in your script, name the real one.

First frame and problem (impact). Title card: "Platform Pal: station announcements, as captions." Then: "Station announcements are made out loud. If you are deaf or hard of hearing and the platform changes two minutes before departure, you find out when the train leaves without you. Screens help, but they lag behind the announcement, and many smaller stations have none."

Solution and what is new (idea). "Platform Pal listens to the announcement through your phone and shows it as a caption within a couple of seconds. If it mentions your train, your phone vibrates. Caption apps already exist. None of the ones we tried knew which train you were on."

Demo (implementation, design). "Here is a recorded announcement from a test we ran at a station. I have saved my train, the 17:42 to Leeds. The announcement plays. The caption appears line by line. It mentions the 17:42 and a change from platform four to platform nine, so the phone vibrates and the new platform number is shown in large type. Now an announcement about a different train: caption, but no vibration. And in a noisy hall, where the transcript is uncertain, the app says so instead of guessing a platform number."

How it works (implementation, stage one). "Audio is streamed in short chunks to the sponsor's speech API, which returns a live transcript. Our matcher looks for train times, destinations and platform numbers, and compares them with the trains you saved. Anything below a confidence threshold is shown as uncertain. The whole loop runs in about two seconds."

Impact and next (impact). "We tested with three hard-of-hearing users, who caught every platform change in our test set. Next we want to test in more stations with different acoustics and add the operator's live departure data as a cross-check. Team: Leila, Marcus and Jun."

What this does deliberately. The sponsor's API is named twice. The demo includes the case where the app should not act (the other train) and the case where it is uncertain, which shows judgement as well as code. And every claim is small and checkable. The user test is three people, and the script says three.

The first frame matters more than the first minute

Judges scrolling a gallery of submissions decide quickly. Two habits help.

Start on a title card, not on your face or your desktop. Two seconds, the project name and one sentence of what it does. It doubles as a good custom thumbnail.

Say the problem before the product. "Station announcements are made out loud" makes a judge care. "Platform Pal is a React Native app using..." makes them check how long the video is.

For the minute-by-minute plan of producing all of this against a deadline, see how to make a hackathon demo video in an hour. This post is about what goes in it for Devpost judges specifically.

Make it

1. 1

   Copy the rubric into your script

   Paste the hackathon's judging criteria at the top of a document and write one labelled paragraph for each. Add a line naming the required API or SDK.

2. 2

   Record the demo with the sponsor tool visible

   One clean take of the main path, plus one case where the app should not act or is uncertain. Large text, notifications off.

3. 3

   Draft the drawn scenes

   In openCanviz, paste the problem, solution, how-it-works and impact paragraphs, choose Keep my wording, and pick whiteboard for the architecture. Generate the voice or record your own.

4. 4

   Check the architecture scene against your code

   Every box should be something you built or called, with the sponsor's API in its own labelled box. Delete anything the draft invented.

5. 5

   Stitch, caption and add a title card

   Title card, drawn opening, demo, drawn closing. Add captions, keep it under the limit, and upload the title card as the custom thumbnail.

6. 6

   Make the story match the video

   Paste the same sentences into Devpost's story sections, expand them with detail, and open the video link logged out to confirm it is public.

Common questions

What happens if my video is over three minutes? It depends on the rules. Commonly, judges are simply not required to watch past three minutes, so anything after that may not count. Some hackathons are stricter. Read yours and stay under.

Can I use unlisted instead of public on YouTube? Only if the rules allow it. Many Devpost rules say publicly visible, and an unlisted or private link can cause eligibility questions. When in doubt, use public.

Can I edit the video after the deadline? Treat it as locked. Many rules require that the submission not be changed after the deadline, and replacing the video on YouTube can count as a change.

Should the whole team appear? Not necessary. Names on the closing card are enough for most judges, and the time is worth more in the demo. If the hackathon is about the team, such as a student event with a team prize, a short on-camera close is fine.

What if part of the project is mocked or hard-coded? Say so on screen. "Payments are simulated in this demo" costs you less than a judge discovering it in your repository. For a longer write-up afterwards, the same structure grows into a portfolio piece; see how to make a video explaining your code for a class submission for the code walkthrough version.