Wie du deine Chancen beim Hackathon verbesserst

Bei Hackathons habe ich einige meiner besten Freunde kennengelernt und mein Studium mit Preisgeldern finanziert. Zwei Dinge haben mir dabei besonders geholfen: frühes Feedback und ein Template, das ich schon kannte.

Beides garantiert keinen Sieg. Du hast aber mehr Zeit für deine Idee, wenn du nicht das halbe Wochenende mit dem Setup verbringst. So arbeite ich mit meinem Open-Source-Hackathon-Starter.

Mach Feedback einfach

Du änderst den Code, jemand aus dem Team testet das Ergebnis. Das sollte schnell gehen. Nach jeder Kleinigkeit auf ein Deployment zu warten, bremst euch aus. Und wer sich um Design oder Pitch kümmert, sollte dafür nicht erst das Projekt installieren müssen.

Für eine Demo teile ich deshalb eine lokale Preview. Im ursprünglichen Projekt habe ich die Livecycle-Docker-Erweiterung genutzt. Damit war ein lokaler Container über eine teilbare URL erreichbar:

Die Screenshots zeigen das damalige Setup. Ein Tunnel oder ein Preview-Deployment erfüllt denselben Zweck. Test dein Tool vor dem Hackathon. Teil nur die App, die du zeigen willst, und nutze Demodaten. Datenbank und Admin-Oberfläche sollten dabei nicht öffentlich erreichbar sein.

Welches Tool du nimmst, ist zweitrangig. Dein Team soll die App ausprobieren können, während du noch daran arbeitest.

Bring ein vertrautes Template mit

Mein Starter ist ein Turborepo-Monorepo mit:

• Next.js für das Frontend in apps/web.
• Hono für die API in apps/api.
• PostgreSQL und Prisma in packages/database.
• Tailwind und shadcn/ui-Komponenten in packages/ui.
• Docker Compose, um die Dienste zusammen zu starten.

Die API könnte auch in Next.js liegen. Ich habe Hono separat genutzt, weil ich gern damit gearbeitet habe. Nimm ein Setup, das du kennst. Prüf vorher auch, wie viel vorbereiteten Code die Hackathon-Regeln erlauben.

Das Repository stammt von 2023 und wird nicht als Produktionsstarter gepflegt. Prüf die Abhängigkeiten, bevor du es öffentlich zugänglich machst. Die Demo-Zugangsdaten sind nur für Demodaten gedacht.

Das Projekt starten

Du brauchst Docker Compose mit Watch-Unterstützung, Node.js und die pnpm-Version aus dem packageManager-Feld im Repository. Klone das Projekt und installier die Pakete:

git clone https://github.com/Code42Cate/hackathon-starter.git
cd hackathon-starter
cp packages/database/.env.example packages/database/.env
pnpm install

Im ursprünglichen Repository gibt es einen Portfehler. Das Frontend ruft http://api:3000 auf, und Compose gibt Container-Port 3000 frei. Im API-Code steht aber PORT=3001. Ersetze die Portkonstante in apps/api/src/index.ts durch:

const PORT = process.env.PORT ?? "3000";

Lass den Aufruf serve({ fetch: app.fetch, port: Number(PORT) }) stehen. Port 3001 gehört zum Host. Innerhalb des Containers läuft die API auf Port 3000.

Starte zuerst Postgres. Erzeuge dann den Prisma-Client und das Demo-Schema:

docker compose up -d postgres
pnpm --filter database db:generate
pnpm --filter database db:push

Die Beispiel-.env zeigt auf localhost:5432/hackathon. Führ diese Befehle deshalb auf deinem Host aus. Der API-Container nutzt den Compose-Hostnamen postgres. db:generate erzeugt nur den Prisma-Client. Erst db:push legt das Schema in der Demo-Datenbank an. Nutze dafür eine Datenbank, deren Inhalt du jederzeit löschen kannst.

Kommt beim Schema-Befehl ein Verbindungsfehler, warte, bis Postgres bereit ist, und versuch es erneut. Starte danach die Apps mit Watch:

docker compose up --watch

Frontend und gemeinsame Komponenten

Auf der Startseite kannst du Benutzer anlegen, anzeigen und löschen:

Die Serverkomponente lädt Benutzer von http://api:3000/users. Der Hostname api funktioniert innerhalb des Compose-Netzwerks. Dein Browser kennt ihn nicht. Für Anfragen aus dem Browser brauchst du eine öffentliche URL oder eine Route, die die Anfrage weiterleitet.

Im UI-Paket liegen die shadcn/ui-Komponenten. Eine weitere Komponente fügst du aus dem Repository-Verzeichnis so hinzu:

pnpm ui:add button

Bleib bei Komponenten, die du kennst. Eine neue UI-Bibliothek spart dir keine Zeit, wenn du sie erst beim Hackathon lernen musst.

Datenbank und API

Prisma hält Schema und Client in einem gemeinsamen Paket. Die API importiert den Client und bietet Routen wie GET /users und POST /users an. Die ursprüngliche Route zum Anlegen eines Benutzers gibt die Anfrage direkt an Prisma weiter. Für eine Demo mit kontrollierten Daten zeigt das den Ablauf. Validierung und Authentifizierung fehlen noch.

Willst du daraus eine echte App machen, prüf die Eingaben und ergänze Zugriffskontrollen. Ersetze die Demo-Zugangsdaten und plane Migrationen. Beim Hackathon hilft ein kleines Datenmodell, das du erklären und bei Bedarf schnell neu anlegen kannst.

Warum Compose Watch hilft

Compose Watch kopiert Codeänderungen in die laufenden Entwicklungscontainer. Änderst du ein Paketmanifest, baut es das Image neu. Hier ist der Ausschnitt für die Web-App:

services:
  web:
    build:
      dockerfile: web.Dockerfile
    ports:
      - "3000:3000"
    develop:
      watch:
        - action: sync
          path: ./apps/web
          target: /app/apps/web
          ignore:
            - node_modules/
        - action: sync
          path: ./packages/ui
          target: /app/packages/ui
          ignore:
            - node_modules/
        - action: rebuild
          path: package.json
        - action: rebuild
          path: ./apps/web/package.json

Für die API gibt es ähnliche Regeln. Die Dev-Server müssen geänderte Dateien selbst neu laden. Eine Datei zu kopieren startet den Prozess im Container noch nicht neu. Die Dokumentation zu Compose Watch erklärt die Aktionen.

Die Dockerfiles nutzen den verkleinerten Workspace von Turborepo. So installieren sie nur die Pakete der jeweiligen App. Danach starten sie die Dev-Server, damit du Änderungen direkt siehst. Für den späteren Produktionsbetrieb brauchst du eigene Images.

Lass Zeit für die Präsentation

Mit Preview und Template steht dein Setup schneller. Was du bauen solltest, musst du trotzdem selbst entscheiden. Such dir einen Ablauf aus, der deine Idee zeigt. Lass jemanden aus dem Team testen und klär offene Fragen, bevor du weitere Features einbaust.

Für den Pitch gibt es meinen Beitrag darüber, warum Entwickler Hackathons verlieren. Dein Template bringt dich schneller zur Demo. In der Präsentation musst du zeigen, wem sie hilft.