Trends

Was ist ein Hackathon?

In zwei Tagen von Problem zu Prototyp: Was hinter dem Format steckt, was es einem Team wirklich bringt und was es ehrlicherweise nicht kann.

Kurz vor fünf, unser Bürohaus in Hamburg-Ottensen voller Laptops. Um Punkt fünf gilt Code-Freeze: Ab jetzt wird nichts Neues mehr gebaut, nur noch gezeigt. Neun Teams sind mit groben Ideen gestartet, eines davon in zwei Besetzungen, jetzt stehen zehn Prototypen zum Pitch. Ein Werkzeug, das eingehende E-Mails aus der Hafenlogistik in strukturierte Planungsdaten übersetzt. Ein Trend-Radar, das für ein Unternehmen die relevanten Entwicklungen herausfiltert. Eine App, die ein monatliches Spendenbudget verteilt und die Wirkung sichtbar macht. Ein Teil der Teilnehmenden hatte vorher noch nie programmiert.

So sah Impulse #12 aus, die zwölfte Ausgabe unserer Impulse-Reihe, im Juni 2026 als AI Hackathon bei uns im Rainhaus in Hamburg. Eine Frage, die uns seitdem immer wieder erreicht: Was ist das eigentlich genau, ein Hackathon? Und lohnt es sich, ein Team dafür zwei Tage aus dem Tagesgeschäft zu nehmen?

Der Begriff, kurz erklärt

Hackathon ist ein Kofferwort aus Hack und Marathon. Hack hat hier nichts mit der Tiefkühltruhe zu tun. Gemeint ist exploratives Bauen: schnell herausfinden, ob eine Idee funktioniert, indem man sie baut statt sie zu beschreiben.

Der Begriff tauchte im Juni 1999 an zwei Orten unabhängig voneinander auf. Am 4. Juni trafen sich rund zehn OpenBSD-Entwickler in Calgary zu einem Kryptografie-Sprint, verlegt nach Kanada, weil US-Exportregeln die Arbeit an Verschlüsselung in den Staaten erschwerten. Elf Tage später forderte John Gage auf Suns Java-Konferenz die Teilnehmenden auf, ein Programm für den damals neuen Palm V zu schreiben. Seitdem gibt es das Format in allen Größen, vom offenen Event mit hunderten Teilnehmenden bis zum internen Zwei-Tages-Format für ein einzelnes Team.

Vier Merkmale bleiben über alle Varianten gleich:

Eine Timebox. Ein fester, bewusst knapper Zeitrahmen, meist ein bis drei Tage.
Kleine Teams. Üblich sind zwei bis fünf Personen, gemischt besetzt: jemand, der das Problem aus dem Alltag kennt, jemand mit Produkt- oder Gestaltungsblick, gern jemand Technisches.
Etwas Lauffähiges. Am Ende steht ein Prototyp, den man anklicken und ausprobieren kann.
Ein Pitch. Jedes Team zeigt vor allen anderen, was entstanden ist und was es gelernt hat.

Der Ablauf ähnelt sich ebenfalls über alle Varianten: Kick-off und Briefing, Teams finden sich, Problem schärfen, bauen, zwischendurch Feedbackrunden, am Ende Pitch und Bewertung. Was danach passiert, ist die eigentliche Frage. Dazu weiter unten.

Wer schon einmal von einem Design Sprint gehört hat: Das ist der durchgeplante Verwandte, fünf Tage mit fester Dramaturgie, entwickelt von Jake Knapp bei Google Ventures. Dort validiert ein Team eine bereits bekannte Frage. Ein Hackathon ist offener, er macht unerwartete Ideen sichtbar und bindet mehr Leute ein. Und der Marathon-Teil des Namens wird überschätzt. Dazu später mehr.

Wo das Format überall läuft

Der Ruf des Formats hinkt seiner Verbreitung hinterher.

Facebooks Like-Button entstand 2007 bei einem internen Hackathon, damals noch unter dem Namen "awesome button". Mark Zuckerberg lehnte ihn zunächst ab. Atlassian veranstaltet seit 2005 quartalsweise ein 24-Stunden-Format mit zwei Regeln: nicht am eigenen Tagesgeschäft arbeiten und in 24 Stunden liefern. Nach 18 Durchläufen bis 2012 standen 550 Projekte und 47 tatsächlich ausgelieferte Features in der Bilanz. Microsoft zieht seit 2014 einen konzernweiten Hackathon auf, 2025 mit über 73.000 Teilnehmenden. Und der Hackathon der Bundesregierung im März 2020 brachte rund 28.000 Menschen zusammen, die an über 1.500 Projekten arbeiteten.

Entsprechend groß ist die Spannweite: offene Events mit tausenden Teilnehmenden, interne Formate für die eigene Belegschaft, Datathons rund um einen konkreten Datensatz, Recruiting-Formate, Civic-Hackathons für Verwaltung und Gemeinwohl. Unser Zwei-Tages-Format für Unternehmens-Teams sitzt am kleinen, geschlossenen Ende dieser Skala. Gearbeitet wird an euren eigenen Fällen.

Muss man dafür programmieren können?

Lange war das die Eintrittskarte, mindestens für einen Teil des Teams. Genau das hat sich in den letzten zwei Jahren gedreht: KI-Werkzeuge wie Claude Code übersetzen eine präzise beschriebene Idee in funktionierenden Code. Die entscheidende Fähigkeit heißt heute Klarheit. Das Problem verstehen, die Nutzer:innen kennen, dem Werkzeug den richtigen Kontext geben. Syntax lässt sich delegieren.

Wie weit das reicht, hat uns beim Testlauf unseres Einstiegs-Cases selbst überrascht. Eine Teilnehmerin, die vorher noch nie mit einer Kommandozeile gearbeitet hatte, sah nach rund 40 Minuten ihre erste kleine Anwendung live im Netz. Direkt für Hackathons gemessen wurde dieser Effekt noch nicht. Aus einem Feldexperiment mit 758 Berater:innen von BCG lässt sich aber die Richtung ablesen: Mit KI-Unterstützung stieg die Ergebnisqualität bei den zuvor unterdurchschnittlichen Teilnehmenden um 43 Prozent, bei den überdurchschnittlichen um 17 (Dell'Acqua et al., 2023). Dieselbe Studie zeigt auch die Grenze. Bei einer Aufgabe, die außerhalb der Fähigkeiten des Werkzeugs lag, lagen die KI-Nutzer:innen deutlich häufiger daneben. Das Werkzeug hebt also am stärksten die, die neu dazukommen. Und es braucht Leute im Raum, die erkennen, wo seine Grenze verläuft.

Für die Praxis heißt das: Ein Team ohne Entwickler:innen funktioniert. Ein Team ohne jemanden, der das Problem wirklich kennt, funktioniert nicht.

Was bringt ein Hackathon einem Unternehmen?

Wir veranstalten selbst welche, ganz unbefangen sind wir also nicht. Trotzdem der Versuch einer ehrlichen Rechnung. Das Wichtigste passiert dabei unterwegs: interaktives Lernen in der Gruppe. Die Ergebnisse geben diesem Lernen den echten Kontext. Vier Dinge passieren verlässlich:

Lernen in der Gruppe. Kein Frontalformat: Alle bauen, und alle lernen voneinander, als Team und über Teamgrenzen hinweg. Fachbereich, Produkt, Design und Technik erleben zwei Tage dasselbe. Was die Werkzeuge können, wo sie an Grenzen laufen, wie man Aufgaben klug schneidet. Danach meinen alle dasselbe, wenn sie über KI reden. Die Mischung zahlt sich messbar aus: In der größten Auswertung von Hackathon-Projekten, 592 an der Zahl, war die Zusammensetzung der Teams der stärkste Erfolgsfaktor. Bei gemischt besetzten Teams lag das Risiko, dass ein Projekt danach einschläft, um 71 Prozent niedriger (Nolte et al., 2020).

Kompetenz statt Bekanntschaft. Tool-Demos und Webinare machen euer Team mit KI bekannt. Kompetenz entsteht erst, wenn Leute an einem eigenen Thema bauen, scheitern und umbauen. Berührungsängste verschwinden durch eigenes Tun, anordnen lassen sie sich nicht. Nebenbei: Seit dem 2. Februar 2025 verlangt Artikel 4 der EU-KI-Verordnung von Unternehmen, die KI-Systeme einsetzen oder anbieten, ein ausreichendes Maß an KI-Kompetenz ihrer Mitarbeitenden. Zwei Tage Bauen an echten Fällen können ein Baustein einer solchen Qualifizierung sein.

Früh wissen, woran ihr seid. Die wertvollste Frage unserer Jury bei Impulse #12 war die einfachste: Wo steckt hier konkret die KI, und was macht sie besser? In zwei Tagen Bauen zeigt sich, ob aus einer Idee etwas wird oder ob sie nur gut klingt. Auch ein Nein ist ein Ergebnis. Zehn Personentage, die klären, ob eine Idee ein Quartal Entwicklungskapazität wert ist: Das rechnet sich in beide Richtungen.

Etwas, das man zeigen kann. Am Ende steht ein Prototyp, den ihr der Geschäftsführung, dem Fachbereich oder Kund:innen vorführen könnt. Ein lauffähiger Prototyp beantwortet Fragen, die zwanzig Folien offenlassen.

Was ein Hackathon nicht ist:

Ein Hackathon produziert keine fertigen Produkte. Die eben zitierte Auswertung zeigt auch: Rund zwei Drittel der Projekte aus offenen Hackathons werden nach dem Event nie weitergeführt. Zur Einordnung: Gemessen wurde die Code-Aktivität öffentlicher, überwiegend studentischer Events. Bei denen gehen Team, Thema und Auftraggeber danach auseinander. In einem Unternehmen sitzen am Montag noch alle am selben Tisch. Das macht den Anschluss nicht automatisch, aber möglich.

Selbst das berühmteste Gegenbeispiel bestätigt das. Microsofts Immersive Reader, heute von Millionen genutzt, entstand 2015 bei einem internen Hackathon. Zum Produkt wurde er, weil danach eine Führungskraft auf das Team zuging und fragte: Was braucht ihr, wie schnell könnt ihr sein?

Ein Hackathon hat also kein Ergebnisproblem, er hat ein Anschlussproblem. Prototypen versanden, wenn vorher niemand entschieden hat, was danach passiert. Deshalb gehört die Anschlussfrage ins Format selbst: Wer übernimmt das Ergebnis, und wer darf beim Pitch entscheiden?

Und noch eine Grenze gehört auf den Tisch. Ein Prototyp ist kein Produkt, das ihr am Montag ausliefert. Er ist bewusst schnell gebaut, um eine Frage zu beantworten. Genau darin liegt sein Wert.

Was nach den zwei Tagen hängen bleibt

Für das Lernen gilt dasselbe wie für die Prototypen. Wochen nach Impulse #12 hat uns eine Teilnehmerin geschrieben, dass sie seitdem wieder an eigenen Ideen sitzt und sie selbst umsetzt. Das passiert nicht bei allen und es passiert nicht automatisch. Aber oft genug, dass sich die Frage lohnt, woran es liegt.

Das Muster kennt man aus der Gestaltungspsychologie. Don Norman beschreibt drei Ebenen, auf denen ein Erlebnis wirkt. Auf ein Format wie dieses übertragen heißt das: Nur eine der drei Phasen findet im Raum statt.

Vorher zählt die Erwartung. Die Wirkung beginnt, bevor jemand den Raum betritt. Sie entsteht aus dem Framing und aus den Fragen, die sich Teilnehmende selbst stellen. Was will ich mitnehmen? Wie bereite ich mich vor? Wer die Einladung als Terminblocker verschickt, verschenkt diesen Teil.

Währenddessen zählt der Struggle. Intensiv, unter Zeitdruck, im Team, an einem echten Problem. Unbequem, und genau deshalb wirksam. In Erinnerung bleibt selten die Dauer. Es bleibt der Moment, in dem es kippt, und die Art, wie es sich auflöst.

Danach zählt das Echo. In den Tagen darauf sortiert sich das Erlebte zu einer Erkenntnis. Und Erkenntnis allein überlebt den Montag nicht. Sie wird erst dann zu verändertem Verhalten, wenn sie einen Anlass bekommt, sich zu wiederholen: einen Auslöser, eine kleine Routine, jemanden, der nachhakt.

Der Struggle allein bleibt ein schönes Erlebnis. Die Erkenntnis allein bleibt Theorie. Deshalb hört unser Format nicht am Freitagabend auf.

Und, muss man das Wochenende durchmachen?

Das Klischee: 48 Stunden am Stück, Schlafsäcke, Pizzakartons, um vier Uhr nachts der Durchbruch. Diese Events gibt es, und sie haben ihren Reiz. Mit unserem Format haben sie wenig zu tun.

Bei uns sind es zwei Arbeitstage, konkret Donnerstag und Freitag, tagsüber, mit Feierabend. Erschöpfte Gehirne bauen keine besseren Prototypen. Und die Nachtschicht ist vor allem ein Filter. Sie sortiert die Leute aus, die abends zu ihren Familien müssen, und damit oft genau die Perspektiven, die ein gemischtes Team braucht.

Statt eines Minutenplans arbeiten wir mit Etappenzielen. Auch das hat einen handfesten Grund: In einer Untersuchung von 13 Hackathon-Projekten lieferte kein einziges der Teams, die mit fertig durchgetaktetem Ablaufplan gestartet waren, am Ende etwas Lauffähiges (Lifshitz-Assaf et al. 2021, referiert in Heller et al., 2023). Wir sehen das Muster auch bei uns. Der meiste Support wird ganz am Anfang gebraucht, beim Schärfen des Problems. Danach entwickeln Teams eine Eigendynamik, bei der ein starrer Takt eher stören würde. Struktur ja, Takt nein.

Wie so etwas bei uns aussieht

Bei uns heißt das Format Impulse, und der Name ist wörtlich gemeint: Ein Impuls setzt Kräfte in Bewegung, genau das soll hier passieren. Für Unternehmens-Teams sind es zwei Tage. Tag 1 ist der Problemraum: Ihr schärft eigene Anwendungsfälle aus dem Team-Alltag, klärt Rahmenbedingungen, die Teams formen sich. Tag 2 ist der Lösungsraum: bauen, testen, am Ende der Pitch vor der Runde. Dazwischen führt eine einfache Dramaturgie von Konzept über User Flow (den Weg der Nutzer:innen durch die Anwendung) und Design zum Prototyp.

Gebaut wird mit Claude Code, dazu Editor, Versionsverwaltung und Deployment. Wenige Werkzeuge, die zusammenspielen, statt zwölf, die erst eingerichtet werden müssen. Für das Mentoring gilt eine einfache Regel: Wir geben keine fertigen Antworten. Wir stellen die Fragen, die weiterbringen. Und die Kriterien für den Pitch liegen vom ersten Moment an offen. Wer erst am zweiten Nachmittag erfährt, worauf geschaut wird, optimiert zwei Tage lang ins Blaue.

Die Anschlussfrage bauen wir von Anfang an ein. Der Anwendungsfall wird vorab in einem gemeinsamen Gespräch geschärft, und zum Ergebnis gehören neben Prototyp und Pitch auch die konkreten nächsten Schritte. Unsere Empfehlung dazu: Beim Pitch sitzt jemand mit im Raum, der über diese Schritte entscheiden darf.

Ein paar nüchterne Eckdaten für die interne Rechnung:

Euer Einsatz: ein Team von bis zu vier Personen, zwei volle Arbeitstage, dazu ein Vorgespräch zur Fallauswahl.
Ort, Moderation, Methodik und die technische Prototyping-Basis stellen wir.
Es muss kein vertrauliches Thema sein. Für den Einstieg funktioniert auch ein anonymisierter oder nachgebauter Fall. Welche Werkzeuge laufen, klären wir vorab mit eurer IT.
Was entsteht, gehört euch: Code, Konzepte, Ideen.

Und ehrlicherweise: Ein Format wie dieses ist nie fertig. Wir schärfen es mit jeder Ausgabe nach.

Ein kurzer Selbstcheck

Vier Fragen:

Gibt es einen konkreten Fall, den ihr klären wollt, eine Vermutung, ein "das müsste doch automatisierbar sein"?
Gibt es jemanden, der das Ergebnis danach übernimmt?
Wäre ein Nein für euch ein brauchbares Ergebnis?
Bekommt ihr die richtigen Leute für zwei Tage frei, auch die aus dem Fachbereich?

Wenn ihr viermal nicken könnt, sind zwei Tage Bauen der schnellste Weg, es herauszufinden. Bauen und gegen die Wand fahren und neu bauen. Ob aus dem Prototyp mehr wird, entscheidet sich ohnehin erst in den Wochen danach. Aber ob es sich lohnt weiterzumachen, wisst ihr nach zwei Tagen.

‍

Impulse ist die Eventreihe von modulr.design, die nächste Ausgabe ist am 8. und 9. Oktober 2026 im Rainhaus in Hamburg. Wenn ihr dabei sein wollt oder mit dem eigenen Team bauen möchtet: Meldet euch gern unverbindlich.

‍

Zum Weiterlesen

‍