Why most hackathon winners never launch, and what to do after the hackathon

Most hackathon winners never launch because the event was designed to end, not to hand over. The belief behind it is that a strong idea, once it has won in public, will find its own sponsor, budget and team. It rarely does. What works instead is to decide the owner, budget and decision date before the event, and then run a deliberate 90-day path from prototype to pilot.

The belief, stated fairly

The belief goes like this: "We run the hackathon, the best idea wins, and leadership, having seen it, will naturally back it. Good ideas sell themselves."

It is not a foolish belief. Hackathons do produce real energy and some strong concepts. Senior leaders do attend the final presentations and often say encouraging things. And there are well-known stories of products that started at hack events. So organisers reasonably assume that visibility plus quality equals adoption.

Why it fails in practice

Nobody's job changed on Monday. The winning team goes back to its day jobs. Their managers did not agree to release them. The prototype sits on a laptop. Visibility created goodwill but no time, and without time nothing moves.

Applause is not a budget. A senior leader saying "this is excellent, let's take it forward" in front of a room is a social act, not a funding decision. The budget for the coming year was set months ago, and nothing in it carries the winner's name.

The prototype was built on sand. To finish in 48 hours, teams fake things: hard-coded data, skipped security, a manual step behind a screen. That is the right way to build a prototype, but it means the gap between demo and production is much larger than the room believes. When the IT team sees the code, the honest answer is "we would need to rebuild this", and enthusiasm drains.

The judges were not the owners. Many panels are chosen for seniority and visibility. Then the people who would have to run the solution, whose systems it touches, whose staff would use it, see it for the first time weeks later, with no stake in it.

Winning was the finish line. Teams were told the goal was to win. Once they have won, the story is complete. Nobody told them that winning was the start of a test.

None of these are failures of the idea. They are failures of design: the event was built to produce a ceremony, and it did.

What works instead

Before the event: build the landing

The decisions that matter most happen weeks before anyone writes code.

1. Name the owner and the landing zone. One person who will take the winner forward, and the budget line or programme that will absorb it. How to run a hackathon that produces something real calls this the one-page agreement.
2. Agree release time in advance. Line managers of likely participants agree that winning teams get a defined amount of time, for example one day a week for six weeks, before the event.
3. Put owners on the panel. Judges include the person who will run the solution and the person whose systems it touches. Use criteria that reward adoptability, not just ambition; see judging criteria that pick the right winner.
4. Run a premortem. Ask the organising team: "It is six months from now and nothing from this hackathon launched. Why?" A premortem usually surfaces the access, budget and release problems while there is still time to fix them.

The 90 days after

Treat the period after the event as a project in its own right.

• Week 1–2: handover. The owner meets each selected team. Agree roles with a RACI, confirm the time release in writing, and list what was faked in the prototype.
• Week 2–4: name the risky beliefs. Use assumption mapping to sort what the prototype assumes about users, systems and cost. Pick the two most dangerous.
• Week 4–8: test them. Write each as a hypothesis test with a pass mark set in advance, and run it with real users or real data at small scale.
• Week 8–12: decide. Go to pilot with a rollout checklist, adapt and test again, or stop. All three are good outcomes if they are deliberate.

Throughout, keep participants and sponsors informed with a simple stakeholder communication plan. Silence after a hackathon is read, correctly, as abandonment, and it shapes whether people sign up next time.

Make stopping respectable

Some winners should not launch. A test in week six may show users do not want it or the cost is too high. That is a good result, bought cheaply. Say so publicly, credit the team for what they learned, and record it. When stopping is treated as failure, owners avoid the decision and projects linger half-alive, which is worse than either outcome. How to stop a project well covers this.

Illustrative example

Illustrative. A university hospital group in the Netherlands ran an internal hackathon on reducing missed outpatient appointments. The winning team, two nurses, a scheduler and a developer, built a reminder flow that let patients rebook with one reply. The chief operating officer praised it from the stage. Three months later, nothing had happened: the developer had moved to another project and nobody owned the patient-messaging system.

The following year the group changed the design, not the event. The head of outpatient services was named owner before registration opened. Line managers agreed one day a week for eight weeks for winners. The messaging system's manager sat on the panel. After the event, the winning team ran a retrospective on the prototype, mapped its assumptions and tested the riskiest, whether older patients would reply to a text, in one clinic. They did, mostly. The pilot extended to three clinics in week twelve.

Common mistakes

• Announcing a winner without announcing a next step. Always say what happens on which date.
• Treating the prize as the reward. For most teams, the real reward is seeing their work used. Prize money without a path tells them the work did not matter.
• Letting the prototype become the product. Rebuild properly once the concept is proven; do not stretch hackathon code into production.
• Forgetting the teams that did not win. Their findings often contain the best evidence of the event. Capture them.
• Running the next hackathon before the last one's winners have a decision. People notice. Read 9 hackathon mistakes organisers keep repeating for more.

Questions people ask

What should happen after a hackathon? Within two weeks, the named owner should meet the selected teams, agree roles and time, and list what the prototype faked. Then test the riskiest assumptions over the following two months and make a clear decision to pilot, adapt or stop.

Why do hackathon projects fail after the event? Usually because no one owns them, no budget is attached, and the team has no time released from their normal work. The idea is rarely the problem; the missing handover is.

How do you keep momentum after a hackathon? Book the first follow-up meeting before the event ends, communicate progress to participants every few weeks, and publish the decision on each winner, including stops. Momentum comes from visible decisions, not from enthusiasm.

Where to go next

The guides that carry a prototype past the event are premortem, assumption mapping, hypothesis test and rollout checklist. For the full map of formats, see every type of hackathon and jam explained.