Prepare a hackathon story that carries beyond the demo

Recognize the problem?

Useful work. An unclear message.

A demo can work and still leave people unsure what they saw, what was built during the event or what to try next. Preparing the story at the submission deadline also leaves little room to check links, explain limitations or fix a recording. Capture the useful decisions while they are fresh, then assemble a small pack around the event’s requirements.

What you will make

Leave with a project description, a screen-by-screen demo script, a submission checklist and one chosen follow-up. Optional public updates reuse that material; the plan follows your event’s actual duration.

What you need

The official event page and current rules, including eligibility, prior-work policy, required tools or attribution, and submission requirements.
Separate build-end, submission and demo times, with their time zone; add an upload/review buffer you can actually keep.
The project’s intended reader, current working flow, usable assets and the people who can confirm each statement.

Step 01

Confirm the event brief before making a promise

Record the event’s format and what judges or viewers need to see. Check whether an existing project is eligible and how new work must be identified. Keep the official rules link beside your checklist. Video length and code-visibility requirements vary; do not assume another event’s requirements apply.

For the fictional Common Ground event, Trailnote’s team records its permitted starting material, the required demo format, and three separate times: stop building, submit, present.

Step 02

Define the smallest result you can explain

Write the user situation, the working flow and what remains outside it. Keep a private note when a test or constraint changes the plan. A narrower result can support a clear demonstration. If you share a progress update, show one useful decision; routine captures do not all need to become posts.

Trailnote demonstrates one sample trip becoming a checklist. Live weather and booking integrations stay outside the prototype.

Step 03

Write the demo as scenes

Open with the task and show the working interaction. For each scene, note what appears on screen, what you will say, the evidence it supports and any fallback. Rehearse within the actual event limit. Label sample data, manual steps and unbuilt behavior where a viewer could otherwise misunderstand.

Scene 1: a sample trip note. Scene 2: the generated checklist. Scene 3: one suggested item and its explanation. Close with the next question, without promising an untested outcome.

Step 04

Assemble and check the submission pack

Prepare the project summary, what you built during the event, technologies and required acknowledgements, screenshots, demo link and known limits. Check every requirement against the official form. Allow time for recording and hosting to finish. Open the submitted page as a viewer and confirm access; a prepared file or Tellshift export is not proof of submission.

Step 05

Give the public story a useful invitation

Adapt approved material to the enabled destinations that fit your audience. A teammate may explain a decision personally while the project account presents the result. Confirm event names, credits and tags before using them. Invite a concrete task or question and skip a public update if it competes with the demo or has become stale.

Step 06

Choose what continues after the event

Record the questions or tests that actually happened. Choose the next experiment, its owner and a review date, or make a pause explicit. Follow up only through an agreed route. Preserve the demo version and its status while the project evolves; later improvements do not rewrite what was submitted.

Fictional worked example

The facts stay. The perspective changes.

The starting material

Fictional Common Ground submission: Trailnote turns one sample trip note into a packing checklist. The team narrowed its demo to that flow. It has no live weather or booking connection and no usage result. A sample recording shows the current interaction. The next chosen task is to check whether a traveler understands the reason for one suggested item.

The company or project voice

The personal perspective

Make it your own

Project, demo and submission pack

Copy this into the tool you already use. Fill in what you know and leave unknowns visible.

Event, official rules link and checked date:
Eligibility / permitted prior work / required acknowledgements:
Build ends [date, time, zone]:
Submission due [date, time, zone]:
Demo slot and maximum duration:
Recording, upload and review buffer:

Project, intended user and task:
What was built during this event:
Working flow and evidence:
Sample data / manual steps / known limits:

Demo scene | on screen | narration | evidence | fallback:
1. Context and task:
2. Working interaction:
3. Result, limitation and next question:

Submission fields and links checked:
Team credits and permitted assets:
Submitter / reviewer:
Actual submission status and receipt, if available:

Optional public update and specific invitation:
Observed feedback:
Continue / retest / pause:
Next action, owner and review date:

Stay faithful to the work

The boundaries to keep.

Common Ground, Trailnote and the described work are fictional examples. They imply no organizer endorsement, partnership, prize or measured result.
Your event’s rules govern eligibility and submission. MLH and Devpost guidance have their own scopes; no universal two-minute demo or prior-work allowance is assumed.
A script is not a produced video, a reviewed pack is not an accepted submission, and a working prototype is not a generally available product.
This guide is a manual preparation method. The public demo does not submit to an event or publish to social accounts.

Make the working demo easy to understand.

Set the brief, respond to a build setback, prepare the story and choose the test you want after the event.

No sign-in required. Progress stays in this browser; nothing is submitted or published. The guided workspace currently uses English. You can prepare content in English or French.

Try the participant journey Hackathon participants