9 hackathon mistakes organisers keep repeating

Most hackathons that disappoint fail for the same handful of reasons, and almost none of them happen during the event itself. They are decided weeks earlier, when the challenge is written, the judges are chosen and nobody is named to own what comes out. Here are the nine mistakes that come up again and again, with what to do instead.

The nine mistakes

1. Running a hackathon because someone wants a hackathon. The event gets booked before anyone has asked what it is for. A date, a venue and a hashtag arrive; a purpose does not. Without a purpose you cannot write a challenge, pick judges or decide what a good outcome looks like, so every later choice is a guess. Instead: write one sentence before anything else: "After this event, we want to have ___, and ___ will act on it." If you cannot fill both blanks, you may need a different format altogether. The comparison in hackathon, design jam or innovation challenge helps you check.

2. A theme instead of a challenge. "Smart cities", "the future of banking", "sustainability". Themes feel generous because they leave room, but teams spend the first six hours arguing about what to work on, then build whatever they already know how to build. Instead: give teams a real problem, owned by a real person, with a real constraint. A good challenge names who is affected, what is going wrong and what is off the table. We cover the craft in how to write a challenge statement people want to solve. A problem tree built with the challenge owner beforehand is the quickest way to find the right level.

3. No owner for what comes out. This is the mistake that explains why so many winners never launch. A team wins, receives a trophy, shakes hands, and on Sunday morning there is no budget line, no sponsor and no next meeting. Instead: before the event, name the person who will receive the winning work and agree what they are prepared to do with it: a pilot, a 90-day build, a funded test. Put that commitment in the brief so teams know what they are competing for. The full follow-through is in what to do after the hackathon.

4. Judging criteria announced at the pitch. When teams only learn the criteria at the final presentation, they optimise for whatever they guess the judges like, usually slides and polish. Judges then disagree because each one is quietly using their own criteria. Instead: publish the criteria with the challenge, explain what each one means in plain words, and brief judges on them the day before. Weight them according to the purpose you wrote in mistake 1. Our piece on judging criteria that pick the right winner goes into scoring sheets and calibration; a weighted decision matrix is the simplest structure to start from.

5. Mentors who show up only for the photo. A list of impressive names is not a mentoring programme. Senior people who drop by for twenty minutes, give three opinions that contradict each other and leave do more harm than good, because teams change direction to please them. Instead: recruit fewer mentors, give each a clear role (domain, technical, user, pitch), schedule their time in slots, and tell them their job is to ask questions, not to redesign the idea. More in mentors at a hackathon: what good looks like.

6. No access to the people or data the challenge is about. Teams are asked to improve a service for patients, citizens or customers who are nowhere in the building, using sample data that bears no resemblance to the real thing. They end up solving an imagined problem. Instead: arrange real users on call during the first day, even three or four is enough, and prepare a realistic, cleaned data set well in advance. If legal or privacy reviews are needed, start them the week you set the date, not the week of the event.

7. Rewarding the best pitch rather than the best work. The final hour is theatre. Teams with a confident presenter and a good-looking deck win, while a team that tested its idea with five users and changed course twice loses because their slides were plain. Instead: ask every team to show evidence: what they tested, with whom, what changed. Give judges time with each team's working prototype before the pitches. Limit slides. You are trying to find the idea most worth pursuing, not the best performer.

8. Too short to build, too long to stay sharp. Some organisers squeeze a hackathon into an afternoon; others stretch it across three exhausting days with no structure. The first produces sketches; the second produces tired people who stop thinking clearly by the second night. Instead: fit the length to what you expect at the end. A tested concept needs roughly a day and a half of working time. A working prototype with real data needs more, and needs check-in points so teams do not drift. Build the agenda backwards from the final demo.

9. No record of who did what. When the event ends, the only trace is a winners' photo. Participants who did serious work, including those on teams that did not win, leave with nothing they can point to, and the organisation loses track of who it should invite back or involve in the pilot. Instead: capture each team's problem framing, what they tested, what they built and who contributed what. Send it to participants and their managers. It is the cheapest way to make people want to come again.

Do's and don'ts

Do

• Write the purpose and the post-event commitment before you book anything.
• Run a premortem with the organising team: "It is three months later and the hackathon achieved nothing. Why?"
• Publish challenge, criteria and prizes together.
• Book the receiving owner's calendar for the week after the event.
• Use a rollout checklist for logistics so the organising team's energy goes into the challenge, not the catering.

Don't

• Don't let the sponsor write the challenge alone; the person who lives with the problem should shape it.
• Don't invite judges who have not read the challenge.
• Don't promise implementation you cannot fund.
• Don't treat participant numbers as the measure of success.

Illustrative example

Illustrative. A regional public transport authority in a mid-sized European city ran its first hackathon on "better mobility". Eighty people came, twelve teams pitched, and the winning team built a route-planning app very similar to three already on the market. Nobody was assigned to take it forward.

For the second event, the organisers started differently. They wrote the purpose first: find a way to cut the number of passengers stranded at night when the last connection is missed, which the operations director agreed to pilot on two routes. They held a problem tree session with drivers and control-room staff, then wrote the challenge as a how might we question with the constraints spelled out: no new vehicles, no new app. Criteria were published with the brief. Three night-shift drivers were on call during the first day. The winning concept, a simple hold-and-notify rule between drivers and the control room, went into a pilot the following month with the operations director as its owner.

The second event was smaller. It was also the first one that changed anything.

Questions people ask

What is the most common reason hackathons fail? No owner for the result. Ideas without someone prepared to fund or pilot them stop the moment the event ends, however good they are. Fix this before you fix anything else.

How many judges does a hackathon need? Three to five is usually enough. More than that slows deliberation and dilutes responsibility. What matters more is that at least one judge is the person who will own the winning idea afterwards.

Should a hackathon have one challenge or several? For an internal event, one or two well-written challenges usually beat five vague ones. Several challenges make sense when each has its own owner and its own resources ready to act afterwards.

Where to go next

Start with the full map of formats in hackathons, jams and challenges: every type explained, then the step-by-step in how to run a hackathon that produces something real. For the preparation, the problem tree, how might we and premortem guides cover most of what goes wrong, and the weighted decision matrix gives your judges a fair structure.