To host a hackathon, you set a goal and a format, publish the rules and judging criteria, open registration, help people form teams, run a timed build with support on hand, collect submissions, score them against the published criteria, reveal the winners, and close with certificates and a report. That is the whole job in one sentence. The rest of this guide is about doing each step so it holds up when 200 people are depending on it at 11:45 p.m.
It is written by a team that has hosted hackathons and game jams for more than five years, so it leans on what breaks on the day rather than what looks good in a planning doc. Each step ends with the kind of tool that handles it; for the full comparison, see our guide to the tools to host a hackathon.
How to host a hackathon: the 10 steps at a glance
- Set the goal and format. Decide why the event exists, who it is for, and whether it runs in person, online or hybrid.
- Build the plan, budget and timeline. Fix the date, venue, staff, prizes and sponsors, working back from the event.
- Write the rules and judging criteria. Publish eligibility, team size, submission requirements and how projects are scored.
- Open registration. Collect only the data you will use, and approve or waitlist against a capacity limit.
- Form teams. Give solo registrants a structured way to find a team before the clock starts.
- Set up communication. One official channel for announcements, one for chat and support.
- Run the build. Kick off, keep the agenda visible, staff mentors, and make deadlines impossible to miss.
- Collect submissions. One form, one deadline, a confirmation for every team.
- Judge and reveal. Assign judges, score with a weighted rubric, check the results, then announce.
- Wrap up. Issue certificates, gather feedback, and send the report to sponsors and stakeholders.
If you want the task list rather than the process, our hackathon organizing checklist breaks every phase into individual jobs.
A hackathon planning timeline
Most first-time hosts start too late. These are the lead times that leave room for the things that always slip: sponsors, judges and the venue.
| When | What should be done |
|---|---|
| 12–8 weeks out | Goal, format, date and budget agreed. Venue held. Sponsor outreach started. |
| 8–6 weeks out | Rules, prizes and judging criteria written. Event page live. Registration open. |
| 6–3 weeks out | Promotion running. Judges and mentors confirmed. Theme or challenge drafted. |
| 3–1 weeks out | Registration closed or waitlisted. Team formation open. Agenda and run-of-show final. |
| Event week | Attendance confirmed. Judges briefed. Submission form tested end to end. |
| Within a week after | Certificates sent, feedback collected, report delivered to sponsors. |
For a public event with 100 or more participants, work to the full 12 weeks. An internal company hackathon can compress it to 4 to 6, because the audience already exists and there is no venue search or public promotion.
Step 1: Set the goal and the format
Start with why. A university hackathon may exist to teach and recruit, a corporate one to test ideas the business will actually fund, a community game jam to grow a scene and ship portfolio pieces. The goal decides the audience, and the audience decides almost everything else: event length, team size, prize structure and how you judge.
Then choose the format. In person gives you energy and simpler logistics on the day but caps attendance at the size of the room. Online removes the venue and widens the pool, but punishes vague instructions. Hybrid gives you both audiences and both sets of problems. Length matters too: 24 to 48 hours suits a prototype, while an async challenge week suits working professionals across time zones. Our guide to online hackathon formats compares seven that work remotely.
If participants will build games rather than software products, you are closer to a game jam, which changes the theme, the submission and the scoring. See game jam vs hackathon for the differences, and how to run a game jam for that format.
Tools: none yet. A one-page brief in a shared doc is enough: goal, audience, format, date, and how you will measure success.
Step 2: Build the plan and the budget
A hackathon budget usually covers the venue, food and drinks for every meal of the event, prizes, swag, software, and any travel for judges or speakers. Sponsors can offset most of it, but sponsors want something back: visibility, access to participants, or a challenge track of their own. Decide what you can offer before you ask.
Name an owner for every stage: registration, participant support, mentors, judging, logistics, communications. The most common planning failure is not a missing task. It is a task everyone assumed someone else had.
If you are deciding whether to run it yourselves or hand it to a partner, agency versus in-house sets out what each model costs and controls.
Tools: a spreadsheet or Notion board for tasks and budget. This is internal planning, and flexible tools do it well.
Step 3: Write the rules and the judging criteria
Publish the rules before registration opens, so participants know what they are joining. Cover eligibility, team size limits, what counts as prior work, what the submission must include (repository, demo video, description, screenshots), the code of conduct, and the prizes.
Write the judging criteria at the same time and give each one a weight. Innovation, execution, impact and presentation are common starting points, but the right mix depends on the goal from step 1. A recruiting event may weight execution heavily; a startup-style event may weight the problem and the market. Participants who can see the criteria build toward them, and judges who have anchors for each score disagree less.
Our hackathon judging criteria guide has a complete rubric, and the free judging criteria builder generates a weighted one you can copy.
Tools: a public event page that holds the rules, schedule and criteria in one place. Rules scattered across a PDF, a pinned chat message and an email get read differently by every team.
Step 4: Open registration
Collect only what you will use: name, contact, experience level, skills, whether they already have a team, and anything tied to eligibility or logistics, such as dietary or accessibility needs. Every extra field lowers completion and adds data nobody reads.
Decide your capacity and what happens past it. Will you approve everyone, review applications, or run a waitlist? Free events tend to see no-shows, so many hosts accept slightly more people than the room holds and ask for a confirmation a few days before. Our guide to hackathon capacity limits covers caps for registration, teams, tracks and judging separately.
Tools: a form builder or ticketing tool works for sign-up. The catch is what happens next: a form response is not a team member, and someone ends up copying rows into the next tool.
Step 5: Help people form teams
Many hackathons assume teams will form on their own. Experienced crowds manage it. Students, first-timers and remote participants often do not, and a participant who cannot find a team is the one most likely to disappear before the build starts.
Give solo registrants a structured way in. Let them list their skills and the kind of project they want, show open teams that need someone like them, and close team formation before kickoff. For a quick, fair split at an in-person event, a random team generator does it in seconds, and a team name generator settles the naming debate.
Tools: a Discord channel is the usual free option, but it favors the loudest voices. A matchmaking board that shows open slots and missing skills works better, especially online.
Step 6: Set up communication
Separate official announcements from conversation. Chat moves fast, and a deadline change posted in a busy channel is gone within minutes. Pick one place that holds the truth (schedule, rules, any change to either) and treat chat as the place for energy, questions and support.
Tell participants where to go when they are stuck, who answers, and how fast. Mentors should know which channel or desk is theirs and when their shifts are.
Tools: Discord for developer and gaming communities, Slack for corporate events, video calls for online kickoffs and demos, and email for the messages that must arrive: acceptance, schedule, submission confirmation, results.
Step 7: Run the build
The kickoff sets the tone. Explain the theme or challenge, the schedule, the submission requirements and the judging criteria, then get out of the way. During the build your job is to keep the agenda visible, keep mentors available, and remind teams what is coming next. The engagement ideas that work best here all remove friction rather than add activities.
Treat the agenda as a control system, not a calendar. Build time can be loose; the submission deadline must be exact. A hackathon agenda template gives you an hour-by-hour schedule for 24- and 48-hour events. In a room, a big screen showing the current phase and a countdown answers the question every team asks every hour. That is what projector mode is for.
Tools: slides and a shared doc work but drift out of date. A live agenda that updates everywhere when you change it once saves a lot of shouting across the room.
Step 8: Collect submissions
Use one submission form with required fields, one deadline with the time zone stated, and an automatic confirmation for every team. The most common panic at the end of a hackathon is not a late team. It is a team that submitted and cannot tell whether it arrived.
Ask only for what judges need to score: a title, a short description, a demo link or video, the repository and screenshots. For a game jam, a playable build. Decide in advance what happens to late or incomplete submissions, and write it into the rules.
Tools: public galleries such as Devpost or itch.io, GitHub for code, or a form for links. The question is whether judges can open each project in the same place they score it, or whether someone builds a spreadsheet of links at midnight.
Step 9: Judge the projects and reveal the winners
Judging is where a hackathon keeps or loses its credibility. Assign judges so the load is even and nobody scores a team they have a conflict with. Give every judge the same weighted criteria. When judges score different subsets of projects, normalize the scores, or a generous judge decides the winner. Decide how ties break before they happen.
Check the results before anyone sees them. Then make the reveal an event: a countdown, third place to first, the room watching. If you add public voting, decide what it is worth against the jury and keep the two separate. Public voting vs jury scoring weighs the options.
Tools: a spreadsheet works with two or three judges, but weighting, normalization and locking all become manual. Judging software does those steps for you and keeps an audit trail you can show a disappointed team.
Step 10: Wrap up, certify and report
The event is not over when the winners are announced. Send certificates while people still care, ideally verifiable ones they can post. Send a short feedback survey within a day or two. Then write the report: registrations, attendance, teams, submissions, completion rate, scores, feedback, and anything sponsors were promised.
That report is what gets the next event approved and the next sponsor signed, so collect the numbers as you go rather than rebuilding them afterward. Event analytics for hackathons covers which numbers matter.
Tools: a design tool plus a mail merge works for certificates at small scale. A QR certificate generator issues them from the event records, so names and awards cannot drift from the results.
How to host a hackathon online
The steps are the same; the margin for error is smaller. Nobody can walk up to the organizer desk, so everything you would have said from the stage must be written down in one place participants can find at 2 a.m. State the time zone on every deadline. Run team formation before the build starts, not during it. Send automatic confirmations for registration and submission, because silence reads as failure. And give the event a live finish, such as a streamed reveal, even if the build itself was asynchronous.
How to host a hackathon at your company
An internal hackathon needs the same ten steps with two changes. First, secure an executive sponsor before you announce anything, because the event only matters if someone with a budget acts on the winners. Second, judge on business value and feasibility, not just the demo. Our guide to running a corporate hackathon goes further, and these internal hackathon examples show formats that produced real decisions.
The most common hosting mistakes
- Defining the event by theme instead of format. A theme is useful. A format is essential.
- Publishing criteria after the build starts. Teams build toward what they can see.
- Leaving team formation to chance. Solo participants who cannot find a team quietly leave.
- Announcing in chat only. Important changes need one place that always holds the truth.
- No submission confirmation. It generates the most support questions of the whole event.
- Unweighted, unnormalized judging. It produces a winner nobody can explain.
- Revealing results before checking them. A wrong name on the screen cannot be taken back.
- Rebuilding the report from scratch. Collect the numbers during the event, not after.
Where HackathonHost fits
Every step above is a handoff when it runs on separate tools, and someone on your team becomes the integration between them. HackathonHost puts the whole event in one workspace: registration, team matchmaking, submissions, weighted jury and public scoring, projector mode, the live reveal, QR-verified certificates and post-event analytics, for hackathons and game jams alike. It is a flat $99 per event with no per-participant fees, and universities get three free events a year.
FAQ
What do you need to host a hackathon? A clear goal and format, published rules and judging criteria, a way to register participants and form teams, a communication channel, a submission process, a judging panel with a scoring rubric, prizes, and a way to announce winners and send certificates. For an in-person event, add a venue, food, Wi-Fi and power for every seat.
How long does it take to plan a hackathon? For a public event with 100 or more participants, 8 to 12 weeks. An internal company hackathon can be planned in 4 to 6 weeks, because the audience already exists and there is no venue search or public promotion.
How much does it cost to host a hackathon? An online hackathon on free tools can cost little more than the prizes. An in-person event adds the venue, catering, swag and possibly travel. Software ranges from free, through flat per-event pricing, to per-seat and enterprise contracts; our platform pricing comparison lays out the models. The cost most hosts forget is staff time spent moving data between tools.
Can I host a hackathon for free? Yes. An online hackathon on free tools costs only what you choose to spend on prizes, and many community events run on donated prizes and sponsor credits. Universities can also host three events a year on HackathonHost at no cost.
How many organizers do you need to host a hackathon? A small event can run with two or three organizers if the tools handle the admin. A 200-person in-person event typically needs a lead organizer and owners for participant support, logistics, mentors and judging, plus volunteers on the day.
How long should a hackathon be? Long enough to produce the deliverable you ask for, and no longer. A prototype fits 24 to 48 hours. Anything that needs user research or stakeholder access needs a week or more, with checkpoints rather than a single deadline.
How do you judge a hackathon fairly? Publish weighted criteria before the event, give every judge the same rubric with clear anchors, assign projects evenly, normalize scores when judges see different subsets, decide tie-breaks in advance, and check the results before the reveal.
What is the difference between hosting and organizing a hackathon? In practice they mean the same thing. "Hosting" tends to put the weight on running the event and the platform it runs on, and "organizing" on the planning around it. Our guide on how to organize a hackathon goes deeper on the planning side.
Start with the stage that hurts most
You do not have to fix every step at once. Look at the last event you ran, find the stage where staff spent the most hours fixing things by hand, and start there. For most hosts that is team formation or judging. Once one stage runs without a person holding it together, the whole event gets calmer. When you are ready to put the entire event in one place, create your first event on HackathonHost.
