Before you start building
Read the rules, judging criteria, required tech, submission format, team size, IP terms and deadline timezone. Put the deadline in a shared calendar.
Write the one-sentence problem, target user and demo promise. If the team cannot agree on those three lines, coding will make the confusion worse.
While you build
Keep a working main branch, a seeded demo account and a fallback script. Hackathon demos fail most often because a team only tests the happy path once.
Track model cost and latency early. A clever agent that times out during judging is not a clever agent in the room.
Before recording or presenting
Rehearse the demo out loud. Show the problem, the input, the transformation and the result without explaining every implementation detail.
Prepare one slide or paragraph on what is technically interesting. Judges need a reason to believe the project is more than a wrapper.
Before final submission
Check that the repo, hosted app, video, team names, screenshots and required forms all open in a private browser session.
Submit early enough to recover from upload failures. Then save proof of submission and the source page rules in case a dispute comes up later.
< read by a human · updated as things change >
browse hackathons