How to run a hackathon that produces something real

To run a hackathon that produces something real, decide what happens to the winners before you decide anything else: who owns them, what budget they draw on and when the decision is made. Then prepare the problem, the data and the people so teams spend the event building, not waiting. The event itself is the easy part; most of the work sits in the six weeks before and the twelve weeks after.

The steps below assume an internal or ecosystem hackathon of one to three days. If you are still choosing between formats, start with every type of hackathon and jam explained.

Before you start: the one-page agreement

Write a single page and get it signed off by the senior sponsor. It holds five lines:

• The problem in one sentence, and why it matters now.
• The owner who will take the winning prototype forward, by name.
• The landing zone: the budget line, team or programme that will absorb the winner.
• The decision date: when, after the event, the owner says go, adapt or stop.
• What "real" means: a pilot with 50 users, an integration test, a procurement request. Be specific.

If you cannot fill this page, you are not ready to run a hackathon. You may be ready for an ideathon or a discovery phase.

Step by step

1. Frame the problem six weeks out

Interview the people who live with the problem: front-line staff, customers, the system owners. Five to eight stakeholder interviews are enough to stop you briefing the wrong problem. Lay out causes and effects with a problem tree, then write two to four how might we questions as the challenge tracks. Each track should be narrow enough that a team of five can build something meaningful in 48 hours, and broad enough that two teams will not build the same thing. Writing the brief itself is covered in how to write a challenge statement people want to solve.

2. Clear access four weeks out

This is where most corporate hackathons quietly fail. Teams arrive and find they cannot reach the API, the data is not cleared, or the sandbox does not exist. Four weeks out, list everything a team will need to touch, and get written approval from IT, data protection and security. Prepare a sandbox with realistic test data. If real data cannot leave its system, create a synthetic set with the same structure.

3. Recruit for mixed teams

Open registration three to four weeks out, and ask people for their skill, not their title. A good team of four to six has at least one builder, one person who knows the domain and one person who will talk to users. Leave room for people to join as individuals and be placed. Avoid whole departments entering as one team; you lose the cross-silo value that justifies the event.

4. Brief judges and mentors two weeks out

Judges should include the owner from your one-page agreement, someone who controls budget and someone who represents the user. Agree the criteria with them before the event and publish them to participants. A sensible set: strength of evidence that the problem is real, fit with the landing zone, feasibility within existing systems, and quality of the prototype. Weight them in a weighted decision matrix. More on this in judging criteria that pick the right winner.

Mentors are not judges. Give each mentor a track, a schedule of check-ins and a brief: ask questions, unblock access, do not take over. See mentors at a hackathon.

5. Run the event around three checkpoints

A 48-hour plan that works:

• Opening (first two hours). The sponsor explains the problem and the landing zone in person. Then the problem owners, not the organisers, take questions. Teams form and choose a track.
• Checkpoint one (around hour six). Each team states its user, its assumption and what it will build. Push teams to list the riskiest beliefs using assumption mapping. Kill duplicates early.
• Checkpoint two (around hour 24). Each team shows something working, even if ugly, and reports one test with a real user or a real system. A paper prototype counts for interfaces that are not yet built.
• Checkpoint three (final morning). Freeze features. The rest is testing, fixing and preparing a short demonstration.

Keep presentations to five minutes plus questions, and demand a live demonstration. Slides about what the product would do are not a prototype.

6. Judge for adoption, not applause

Run the judging as a challenge panel: each judge scores privately against the published criteria before any discussion, then the panel compares scores and discusses only the gaps. Announce not just the winner but the next step: "The owner will meet this team on Tuesday to plan a four-week pilot." If you announce a prize but no next step, people will understand exactly what the event was.

7. Hand over within ten working days

Within ten working days of the event, the owner meets each selected team, agrees who does what using a RACI, and books the time the team needs, in writing, with their line managers. Run the first pilot steps against a rollout checklist. On the decision date, the owner says go, adapt or stop, and says it publicly. Why most hackathon winners never launch goes deeper into this phase.

Illustrative example

Illustrative. A regional insurer in Southern Europe wanted to shorten the time between a customer reporting a minor car claim and receiving payment. Its innovation lead wrote the one-page agreement first: the claims director owned the result, the claims digital programme would absorb it, and a decision would be made six weeks after the event.

Four weeks out, IT built a sandbox with anonymised claim records and a copy of the document-upload service. Teams of five mixed adjusters, developers and a call-centre agent. At checkpoint two, one team had found, by phoning three recent claimants, that the delay was not assessment but customers sending the wrong photographs. It built a guided photo flow and tested it with call-centre staff playing customers. It won on evidence and fit, not on polish. The claims director met the team the following Tuesday, and a four-week pilot ran with one branch.

Do's and don'ts

Do

• Get the one-page agreement signed before you announce the date.
• Have the problem owner, not the organiser, brief the teams.
• Publish judging criteria at registration.
• Feed people well and let them sleep. A team that slept builds better on day two.
• Record what each team learned, including teams that did not win; their findings often save the winner from repeating mistakes.

Don't

• Start with the venue, the branding or the prize.
• Let teams discover on the morning that they cannot access the systems.
• Allow a slide deck in place of a demonstration.
• Pick judges who will never see the project again.
• Celebrate on Friday and go silent on Sunday. 9 hackathon mistakes organisers keep repeating lists the rest.

Questions people ask

How long should a corporate hackathon be? Two days is the practical minimum for something that works; 24 hours suits only very narrow problems. Longer than three days and you are running a sprint, which is fine, but plan it as one.

How many people do you need to run a hackathon? For 50 to 80 participants, plan on one lead organiser, one technical lead for access and environments, one mentor per track, a judging panel of three to five, and someone dedicated to logistics. The technical lead is the role most often missing.

Should hackathon participants be paid or given time off? Internal hackathons should be held in work time or compensated, and managers should agree in advance. If people have to give up a weekend unpaid, you will only hear from those who can, and you will lose them at the pilot stage.

Where to go next

The guides that do most of the work here are problem tree, assumption mapping, weighted decision matrix and rollout checklist. Each takes under an hour to run with a team.