Hackathons, jams and challenges: every type explained

There are about a dozen kinds of time-boxed innovation event, and they differ in three things: who takes part, what they are expected to produce, and what happens after. A hackathon builds working software or hardware; a jam designs and prototypes a service or experience around a theme; an innovation challenge invites solutions to a stated problem over weeks or months. Pick the type by the output you need on Monday morning, not by the name that sounds most exciting.

This guide maps every common format, says what each one is good and bad at, and points you to the deeper articles in this hub.

The three questions that sort every format

Before the names, the logic. Every event in this family answers three questions differently.

1. Who is in the room? Your own staff (internal), invited partners (ecosystem), or anyone who registers (open).
2. What counts as done? Working code, a physical object, a tested service prototype, a data analysis, or a well-argued concept.
3. How long is the clock? A single day, the classic 48 hours, or a challenge that runs for weeks with stages.

If you can answer those three for your situation, the format almost chooses itself. Organisers who skip them end up running a "hackathon" whose real goal was employee engagement, then wonder why nothing ships. For a side-by-side decision, see hackathon, design jam or innovation challenge.

Hackathons: building things fast

The word dates from June 1999, when OpenBSD developers and, separately, Sun Microsystems at its JavaOne conference both used it for intensive programming events. The core idea has not changed: small teams, a short deadline, and something that runs at the end.

Corporate (internal) hackathon. Staff from one organisation form mixed teams to build prototypes against business problems. Good for surfacing internal talent, cutting across silos and testing ideas that would never survive a budget committee as a paper proposal. Weak when leadership has no plan, owner or budget for what wins. Read why most hackathon winners never launch before you book the venue.

Civic and government hackathon. A public body opens its problems, and often its data, to developers, designers and citizens. NASA's International Space Apps Challenge, held every year since 2012, is the best-known global example. These events build trust and bring outside skills into government, but they need a clear route for a prototype to reach a real service, or they become goodwill exercises. Hackathons for public good covers cause-led versions.

Open (public) hackathon. Anyone can register. You gain range, energy and people who have never seen your problem before. You lose control over intellectual property, confidentiality and follow-through, because most participants go home to other jobs. The trade-off is laid out in internal hackathon or open to the public.

Ecosystem hackathon. Several entities share one challenge that none can solve alone: a regulator, two banks and a fintech community; a ministry, a university and hospitals. Teams are deliberately mixed across organisations. The hardest part is not the weekend but agreeing beforehand who owns the problem and who funds the winner. See the ecosystem hackathon.

Jams: designing services and experiences

A jam borrows the hackathon's clock but changes what counts as done. The output is a prototype of a service, experience or game, tested with real people where possible, rather than production code.

Service jam. The Global Service Jam was started in 2011 by Adam Lawrence and Markus Hormess of WorkPlayExperience. Teams in many cities work for 48 hours on the same secret theme, revealed at the start, then publish their prototypes online under an open licence. The method is service design with a bias for "doing, not talking": go out, talk to people, build a rough version, test it, change it. It is the best format for teaching an organisation how service design actually feels.

GovJam. The same model aimed at the public sector. GovJam was co-initiated in 2012 by the Australian Government with WorkPlayExperience and Protopartners, and the Global GovJam has run in cities around the world since 2013. Public servants, designers and citizens work side by side for 48 hours on a shared secret theme. A sister event, the Global Sustainability Jam, applies the same approach to sustainability.

Design jam. The generic, locally run version: a day or two on a design problem, often user experience or a specific service, with a facilitator leading research, ideation and prototyping. Lighter to organise than a hackathon because nobody needs a development environment, and open to people who do not code.

Game jam. Teams make a playable game against a theme. The Global Game Jam, founded by Susan Gold, Ian Schreiber, Gorm Lai and Foaad Khosmood and inspired by the Nordic Game Jam, first ran in January 2009 at 53 locations. It runs for 48 hours, usually in late January, with the theme given at the start. Organisations use game jams less for games than for what they train: scoping hard, shipping something whole and playable in two days.

How to run one of these yourself, theme and all, is covered in running a jam.

The "-athon" variants: same clock, different output

Ideathon. Teams develop concepts, not builds. The output is a problem framing, a solution concept, a rough storyboard and a pitch. Useful early, when you do not yet know which problem matters, or when participants lack technical skills. The risk is that a polished pitch is mistaken for evidence. Insist on at least one conversation with a real user per team.

Datathon. A hackathon focused on analysing and combining datasets rather than building software. The output is an insight, a model or a visualisation that answers a question. It only works if the data is ready, cleaned and cleared for use before the day; most failed datathons die in the first three hours of permission problems.

Makeathon. Physical prototyping: hardware, electronics, product models, often in a fab lab or maker space. You need tools, materials, safety briefings and technicians, and the clock tends to be longer because objects take time to make and break.

Innovation challenges: the long format

An innovation challenge (sometimes called an open call or a prize challenge) publishes a problem and invites solutions over weeks or months, usually in stages: submission, shortlist, development with support, final selection. It suits problems that cannot be cracked in 48 hours, solvers who are already working on the problem (startups, research groups, suppliers), and organisations that want a pipeline of pilots rather than a weekend of energy.

A challenge lives or dies by its statement. Too broad and you get a pile of generic apps; too narrow and you have written a procurement tender. How to write a challenge statement people want to solve covers this in depth, and judging criteria that pick the right winner covers the selection stages.

A quick map of all the formats

How to choose, in five steps

1. Write the Monday-morning sentence. "After this event, we will have ___ and ___ will own it." If the blank is "a working prototype our IT team will take forward", you want a hackathon. If it is "three tested service concepts the customer experience team will pilot", a jam. If it is "two startups contracted to pilot", a challenge.
2. Check the problem is ready. Frame it with a problem tree and turn the core into a few how might we questions. If you cannot do that, run an ideathon or a discovery phase first.
3. Match skills to output. Working code needs developers on most teams. Service prototypes need people who will talk to strangers. Data events need clean, permitted data.
4. Decide the after before the during. Name the owner, the budget line and the decision date for winners. How to run a hackathon that produces something real builds this into the plan.
5. Pick judges and mentors for the output, not the photo. Judges who will own the result; mentors who know the problem. See mentors at a hackathon.

Illustrative example

Illustrative. A mid-sized city transport authority in northern Europe wanted to reduce missed connections for older passengers. Its first instinct was an open hackathon with a prize for the best app. In planning, the team wrote its Monday-morning sentence and found it did not want an app at all: it wanted to know which part of the journey failed and which service changes staff could make within the current budget.

It ran a two-day service jam instead, with drivers, station staff, a few older passengers and two designers. Teams spent the first morning riding routes and interviewing passengers, built storyboards and paper prototypes of announcements, signage and a "connection buddy" role, and tested them at a real interchange. A challenge panel of the operations director and two station managers chose two concepts to pilot. A hackathon came six months later, with a narrow brief: build the real-time connection alert that the jam had shown passengers actually wanted.

Do's and don'ts

Do

• Choose the format from the output you need and who will own it.
• Publish the problem, the judging criteria and what winners receive before registration opens.
• Mix teams on purpose: domain experts with builders, juniors with seniors, insiders with outsiders.
• Plan the 90 days after the event as carefully as the 48 hours of it. A rollout checklist helps.
• For ecosystem events, draw an ecosystem map and agree ownership before inviting anyone.

Don't

• Call an engagement event a hackathon and then promise implementation.
• Run a datathon before the data is cleared, or a hackathon with no access to the systems the prototype must touch.
• Let the pitch decide everything. Score evidence and feasibility with a weighted decision matrix, not applause.
• Copy a global jam's secret-theme mechanic for an internal event where you already know the problem. Secret themes suit learning events, not targeted problem-solving.
• Repeat the classic errors listed in 9 hackathon mistakes organisers keep repeating.

Questions people ask

What is the difference between a hackathon and a jam? A hackathon is judged on what works: code, hardware, a running prototype. A jam is judged on a designed and tested service or experience, and usually needs no coding. Both often run for 48 hours, but a jam spends far more of that time with real users.

What is the difference between a hackathon and an ideathon? An ideathon ends with concepts and pitches; a hackathon ends with something built. Use an ideathon when the problem is still fuzzy or the participants are not technical, and a hackathon when the problem is clear and you have builders.

Is an innovation challenge the same as a hackathon? No. A challenge runs over weeks or months in stages and attracts solvers who already have capability, such as startups and research teams. A hackathon compresses everything into a few days and starts most teams from zero.

Where to go next

Start with the guides that shape the problem before any event: problem tree and how might we. For the build and test phase, use paper prototype and storyboard, and for selection, a challenge panel. All method guides are at the guides index.