How to Run a Hackathon: A Step-by-Step Guide for First-Time Organizers

Most of what decides whether your hackathon works happens weeks before anyone shows up. The room will feel busy and slightly chaotic either way. Whether people leave with something worth continuing depends on four earlier choices: what you are trying to achieve, who you invite, what you ask them to build, and how you judge it.

This guide walks through the ten steps we use with universities, public sector teams and companies running their first event. It is written in order, because the order matters.

Step 1: Define the goal and the outcome you will measure

Write one sentence describing what the event should produce, in terms you can check a month later. "Run a great hackathon" fails that test. These pass:

• Recruiting: 30 qualified candidates in the talent pipeline.
• Innovation: 5 prototypes worth funding a next step.
• Community: 150 students from 6 faculties working across disciplines.
• Partnerships: 4 sponsors with a reason to come back next year.

Everything downstream points back at that sentence. Challenge brief, judging weights, who you invite, what you spend on prizes. When a decision does not serve it, drop the decision.

Step 2: Pick the format, length and audience

Three variables define the shape of your event: who takes part, how long it runs, and whether everyone is in one room.

• 24 to 48 hours, in person. The classic. Highest energy, highest logistics cost, best results for working prototypes and for teams that did not know each other on Friday.
• One day sprint. Much easier to staff, and much easier to get corporate teams released from work for. Expect concepts and clickable mockups, not running code. This is usually the right first event for a company that has never done one.
• Two weeks, part time, online. Wider reach, deeper results, and more work for you than it looks. Teams drift when nobody is watching, so you need a fixed weekly check-in, a visible submission tracker, and someone whose actual job that fortnight is chasing quiet teams. Half of them will go quiet at least once.

Set a target headcount early. It drives venue, catering, mentor count and prize budget all at once. For a first event, 60 to 100 participants in 12 to 20 teams is manageable. University programs and internal company programs pull in different directions on rules, timing and incentives, which we cover for universities and for companies.

Step 3: Build the timeline

Eight weeks is enough if you start recruiting participants in week one. Six weeks is tight but survivable. Under four weeks, plan for a small crowd and be at peace with it.

Our free Hackathon Blueprint Generator will draft this timeline, a budget range and a format recommendation from a few answers, if you would rather start from something than from a blank page.

Step 4: Budget and sponsors

Costs swing wildly by country and venue. The line items barely change:

1. Venue and furniture, or nothing if you use your own space
2. Food: three meals plus snacks per participant for a 48 hour event
3. Prizes: cash, credits, or a paid pilot
4. Mentor and judge travel
5. Promotion, print and merchandise
6. Tooling: registration, submissions, scoring

Prizes are where first-time organizers overspend. Doubling the cash pool rarely changes who enters. A real next step does: a funded pilot, an internship offer, a meeting with the person who owns the budget. Strong teams are already deciding whether the weekend leads anywhere, and they can tell the difference between a cheque and an opening. Sponsors read the same way. Sell them access to teams and problems rather than a logo on a t-shirt, and the conversation about next year gets much easier.

Step 5: Write the challenge brief and the rules

A vague brief produces vague results. Give teams a real problem, real constraints, and a clear definition of done:

• The problem and who suffers from it today
• Any data, API or environment you will provide
• What a submission must contain: repo or file, demo, short deck
• Boundaries: team size, allowed pre-work, use of AI tools, IP ownership

Publish the IP terms before registration opens. This is the single most common source of friction with corporate participants and with university legal teams, and it is much harder to fix once people have signed up under different assumptions. Theme design deserves its own thought, and we go deeper in defining impact-driven hackathon themes.

Step 6: Recruit mentors and judges

Aim for one mentor per two or three teams, on a rota so nobody works 48 hours straight. Brief them in one line: help teams narrow scope, do not build for them.

Book judges four weeks out and put the scoring sheet in their hands a week before the event, not on the morning. A domain expert, a business voice and a technical reviewer will disagree usefully; three people from the same background will agree on the wrong winner. Think about who feels welcome in the room too, which is the practical subject of our guide on creating an inclusive hackathon.

Step 7: Set scoring criteria before anyone pitches

Decide how you will score, publish it with the rules, and give every judge the same sheet. Weighted criteria are the norm: problem fit, solution quality, technical execution, feasibility, presentation. Four to six criteria works. Beyond that, judges stop scoring and start guessing.

You can build the sheet in a few minutes with our free Judging Rubric Builder, and the hackathon judging rubric blueprint explains how to set the weights and keep one loud judge from steering the result.

Step 8: Run the event day

A tight run of show removes most of the day-of stress. A workable 48 hour shape:

• Hour 0. Welcome, challenge briefing, rules, judging criteria on screen.
• Hour 1. Team formation for anyone without a team, then a scope check with a mentor.
• Hour 4, then every few hours. Mentor rounds, one table at a time.
• Hour 24. Mid-point checkpoint. Every team says out loud what they will demo.
• Hour 40. Submissions freeze. Coding stops, slides start.
• Hour 44. Pitches, judging, deliberation, awards.

Announce the submission deadline at least three times and then actually hold the freeze. Teams that keep coding until the pitch pitch badly, every time.

Two things nobody warns first-time organizers about. The first is food rhythm. Hot meals land better slightly earlier than you think, because teams skip them when they are deep in a problem, and a late dinner turns into no dinner. Keep fruit, water and something salty available all night, and put the caffeine somewhere people have to stand up and walk to.

The second is the dip. Somewhere around hour 20 to 30, usually after the mid-point checkpoint, the mood in the room drops. Teams have discovered their idea is harder than it looked, a few people have not slept, and someone will quietly decide they are going to lose. This is normal and it passes, but only if you plan for it. Have mentors circulating rather than sitting, give teams permission to cut features instead of failing, run something loud and short to break the silence, and tell people at the start that a low point around dawn is part of the format. If you have a quiet room with a few mattresses, say so at hour 0; participants who know they can sleep for two hours usually come back sharper than the ones who tough it out.

Step 9: Judging, pitches and prizes

Give every team the same slot, usually four or five minutes plus two for questions, with a timer visible to the room. Send the expected pitch structure out in advance so teams are not inventing a narrative at 3am; we break down a workable one in how to build a hackathon pitch deck. Our Pitch Timer handles the clock if you need one.

Collect scores first, discuss second. Talking before scoring lets the most confident judge set the anchor everyone else adjusts to.

If your event is online or hybrid, judging needs more structure, not less. Fix a single submission deadline in one stated time zone and treat a demo video as the primary artefact, because live remote demos break in ways nobody can debug on a call. Run pitches in one shared session rather than parallel rooms so all judges see all teams, keep the same timer discipline, and have judges submit scores in a form before deliberation opens. Hybrid is the hardest case: put every judge on the same side of the screen, either all in the room or all remote, or the remote ones will consistently score lower simply because they can hear less.

Step 10: Follow-up, the part most organizers skip

Momentum dies in the week after the event, and it dies quietly. Decide who owns the follow-up before you run the event:

1. Publish results, photos and team summaries within 48 hours.
2. Book next-step meetings with the top teams while they are still excited.
3. Send sponsors a short report against the goal from step one.
4. Survey participants and mentors while memory is fresh.
5. Decide, in writing, which prototypes get resources and which do not.

The last one is uncomfortable and worth doing anyway. A clear no is better for everyone than six months of silence, and it is the only way the next event has a track record to point at.

Common mistakes first-time organizers make

• Opening registration before the challenge and the IP terms are ready.
• Judging criteria invented on the last afternoon.
• Too many themes, so no theme gets a good solution.
• Mentors who take over the build.
• No mid-point checkpoint, so teams find their scope problem far too late.
• Prizes with no path to a next step.
• Nobody owning follow-up once the room empties.

Frequently asked questions

How long should a hackathon be?

24 to 48 hours for a prototype-focused event, one day for a concept sprint, one to two weeks part time when participants cannot clear their calendars. Longer is not better; 72 hour events mostly buy you tired teams and slightly more polish.

How much does it cost to run a hackathon?

Food, prizes and venue dominate everything else. A modest in-person event for 80 people can run on a few thousand euros if you use your own space and offer non-cash prizes. Add an external venue, travel for judges and a large cash pool and it multiplies quickly, which is why the goal sentence from step one matters: it tells you which of those you actually need.

How many participants do I need?

60 to 100 is a comfortable first event, giving you 12 to 20 teams. Below 20 people the atmosphere never quite arrives. Above 150 you need a bigger crew than most first-time organizers have.

Do participants need to be developers?

No. Mixed teams with design, domain and business skills usually submit stronger work, especially when the challenge is a real operational problem rather than a coding puzzle. Requiring code narrows your applicant pool for no gain.

How do I judge a hackathon fairly?

Publish weighted criteria before the event, give every judge the same sheet, score independently before any discussion, and hold every pitch to the same clock.

What to do first

If you only get one thing right, make it step one. Write the sentence describing what this event should produce, then show it to the person who approved the budget and make sure they agree it is the sentence. Everything else in this guide is downstream of that agreement, and every first event that ends in a room full of good energy and no next step got it wrong at that first line.

When you have the sentence, put the eight-week timeline in a calendar and start recruiting participants the same week. That is genuinely the whole start.