Von "Klar, kann ich machen!" bis zum Live-Ticketsystem – Eine 3,5-Wochen-Odyssee

Der Moment, in dem alles begann

Februar 2026. Vorstandssitzung der Faschingsgruppe Steigerwald e.V.

Das Thema: Gründungsfest im Juli mit Live-Band. Die Frage: "Sascha, kannst du sowas wie Eventim bauen?"

Meine Antwort: "Klar, ist das möglich!"

Die Wahrheit: Ich hatte absolut keinen Plan wie.

Aber ich wusste: Wenn Eventim es kann, muss es irgendwie machbar sein. Und vor allem – ich wollte, dass wir die volle Kontrolle über unser eigenes System haben. Keine Black Box. Keine Abhängigkeiten. Kein "Sie müssen auf Version X upgraden" oder "Feature Y kostet extra".

Nur: Wie baut man ein Ticketsystem?

Spoiler: Man lernt es, während man es baut.

Warum überhaupt selbst bauen?

Die naheliegende Frage: Warum nicht einfach Eventim?

Die Antwort ist simpel: Kontrolle.

Eventim ist eine Black Box. Du weißt nicht genau:

• Welche Daten werden wie gespeichert?
• Wie sieht die Gebührenstruktur wirklich aus?
• Was passiert bei technischen Problemen?
• Kannst du das System anpassen wenn du willst?

Für ein großes Konzert? Klar, nehm Eventim. Für unser Vereinsfest mit 800 Gästen am Abend und insgesamt 1.100 Besuchern über den Tag? Da wollten wir unser eigenes Ding.

Plus: Als Entwickler ist so ein Projekt die perfekte Gelegenheit zu lernen. Von PDF-Generierung bis PWA Scanner-Apps – alles dabei.

Die technische Architektur

Der Tech-Stack:

Warum dieser Stack?

Ehrlich gesagt: Weil ich damit am schnellsten vorankam. PHP kenne ich, MySQL auch. FPDF war nach mehreren Versuchen mit anderen PDF-Generatoren die beste Lösung. Keine Over-Engineering-Frameworks – einfach das was funktioniert.

Die technische Umsetzung: PHP-Code für die PDF-Ticket-Generierung

Die Timeline: Von 0 auf Ticketsystem in 3,5 Wochen

Woche 1: "Wie schwer kann's schon sein?"

Tag 1-3: Research & Setup

• Wie funktioniert überhaupt ein Ticketsystem?
• Welche PDF-Library nehme ich?
• Wie generiert man QR-Codes?
• XAMPP aufsetzen, erste Datenbank-Struktur

Tag 4-7: Basis-Ticketshop

• Einfaches Formular: Name, Email, Anzahl Tickets
• Datenbank-Einträge
• Erste PDF-Tests (die sahen... grottig aus)

Woche 2: Die PDF-Hölle

Die größte Herausforderung des ganzen Projekts: Ein Ticket das auch so aussieht.

Ich habe gefühlt 5 verschiedene PDF-Generatoren getestet:

• TCPDF → zu aufgebläht
• mPDF → Probleme mit Logos
• Dompdf → langsam
• FPDF → BINGO!

Das Problem mit FPDF:
Alles ist pixelgenau positioniert. Kein HTML/CSS "mach mal hübsch". Nein. Du sagst:

$pdf->SetXY(20, 50); // Logo hier!
$pdf->Cell(80, 10, 'Ticketnummer: 001'); // Text da!

Was auf dem Ticket drauf musste:

• Event-Name & Datum
• Veranstalter (Faschingsgruppe Steigerwald e.V.)
• Act am Abend (Band-Logo!)
• Unser Logo
• QR-Code (für Scanner)
• Ticket-URL
• Käufer-Name
• Preis
• Ticketnummer

Und alles sollte auch noch gut aussehen!

Ich habe Tage damit verbracht Logos einzufügen und Texte zu positionieren. Weil FPDF mit HTML nix anfangen kann – alles manuell per Code.

Das finale Ticket-Design – Dark Theme mit allen wichtigen Informationen

Fails:

• Logo zu groß → überlappt Text
• Text zu lang → geht über Seitenrand
• QR-Code falsch positioniert → unlesbar beim Scannen
• Encoding-Probleme (Umlaute: ä, ö, ü)

Woche 3: Scanner-App & Admin-Dashboard

Die Scanner-App (PWA):

Anforderung: Am Event-Tag müssen Helfer mit dem Handy die QR-Codes scannen können.

Lösung: Progressive Web App mit HTML5 Camera API

Wie's funktioniert:

1. Helfer öffnet Scanner-URL am Handy
2. Kamera aktiviert sich
3. QR-Code vor Kamera halten
4. System prüft in Echtzeit:
   • Gültig → Grüner Screen, Person darf rein
   • Bereits gescannt → Roter Screen, "Ticket bereits verwendet!"
   • Storniert → Roter Screen, "Ticket ungültig!"

Jeder QR-Code ist einmalig. Keine Duplikate möglich.

Problem: Offline-Funktionalität fehlt noch. Wenn am Event-Tag kein Netz ist... Aber für die Testphase erstmal egal. (Learning für v2.0!)

Das Admin-Dashboard:

Was Veranstalter sehen müssen:

Der "Red Button":
Nach dem Event → alle QR-Codes werden gelöscht (DSGVO). Alles andere in der DB wird verschlüsselt archiviert (Aufbewahrungsfrist für Buchhaltung).

Excel-Export:
Für die Buchhaltung. Alle Transaktionen als .xlsx

Woche 3,5: Zahlungssystem & Email-Automation

Zahlungssystem: Vorkasse

Warum kein PayPal/Stripe?
→ Ehrlich gesagt: Keine Ahnung von deren Politik.

Plus: Vorkasse ist für Vereine simpler. Keine Gebühren (außer normale Bankgebühren).

Wie's funktioniert:

1. Kunde bestellt Ticket
2. Bekommt Email: "Bitte überweise X€ auf Konto Y mit Verwendungszweck Z"
3. Zahlung geht ein
4. Manuell: Admin markiert Zahlung als eingegangen
5. System verschickt automatisch: Rechnung + PDF-Ticket

Das Bestellformular – einfach und übersichtlich

Email-Flow (PHPMailer):

Problem:
Der Email-Versand ist langsam. Manchmal dauert's bis zu 30 Sekunden bis die Mail raus ist.

Grund:
FPDF generiert PDF → PHPMailer hängt's an → Versand.
Alles synchron. Kein Queue-System.

TODO für v2.0:
Background-Jobs für Email-Versand. Aber für den Start im April/Mai 2026 sollte's reichen. Optimierung kommt noch.

Die größten Fails & Learnings

Fail #1: "Ich teste mal direkt Live"

Was passierte:
Erste Tests direkt auf Live-System gemacht.

Ergebnis:
Testdaten in echter Datenbank. Chaos. Panik.

Fail #2: PDF-Generator-Hopping

Wie erwähnt: 5 verschiedene Libraries getestet bevor FPDF passte.

Fail #3: QR-Code Position

Erster QR-Code: Zu klein, zu nah am Rand, Scanner konnte ihn nicht lesen.

Fail #4: "Ich plane einfach mal drauf los"

Kein richtiges Konzept am Anfang. Einfach angefangen zu coden.

Ergebnis:
Features 2-3x neu gebaut weil die Architektur nicht gepasst hat.

Was hat das Ganze gekostet?

Was hätte Eventim gekostet?

Ich habe gar nicht mehr recherchiert weil das System so gut lief. Aber typische Ticket-Plattformen nehmen:

• 10-15% Gebühr pro Ticket
• Plus Service-Fee für Käufer

Beispiel-Rechnung:

800 Tickets à 20€ = 16.000€ Umsatz
Eventim-Gebühr (12%): 1.920€
Service-Fee (ca. 2€/Ticket): 1.600€
= 3.520€ Kosten

Unser System: 0€ laufende Kosten
Ersparnis: 3.520€

Plus: Volle Kontrolle über System, Daten, Features.

Live-Performance & Status Quo

Stand März 2026:

• System läuft
• Testtickets erfolgreich generiert
• Scanner-App funktioniert
• Email-Versand etwas langsam (wird noch optimiert)

Verkaufsstart: April/Mai 2026
Event: Juli 2026

Erwartete Zahlen:

• 800 Tickets für Abendprogramm (Band)
• ~1.100 Gesamt-Besucher über den Tag
• Nachmittags: Offenes Programm (kein Ticket nötig)
• Abends: Kartenbetrieb + Geländeräumung

"Sehr geile Geschichte!"

Aus dem Verein kamen Fragen: "Hast du das wirklich so selbst gebaut?"

Ich hab's dann live präsentiert – von der Bestellung über PDF-Generierung bis zum Scanner.

Die Gesichter waren unbezahlbar.

Was ich dabei gelernt habe

Technisch:

1. PDF-Generierung in PHP (FPDF von Grund auf)
2. QR-Code Integration
3. PWA-Entwicklung (Progressive Web Apps)
4. HTML5 Camera API
5. Email-Automation mit PHPMailer
6. Datenbank-Design für Ticketsysteme
7. Staging vs. Production (Testumgebungen!)

Mental:

1. "Klar kann ich das!" sagen ist okay – auch wenn man's noch nicht kann. Man lernt's halt dann.
2. Ruhig bleiben bei Fehlschlägen. 5 PDF-Generatoren getestet? Normal. Einfach weitermachen.
3. Erst überlegen, dann coden. (Hab ich nicht gemacht. War chaotisch. Nächstes Mal besser.)
4. Fertig ist besser als perfekt. Email-Versand ist langsam? Okay. Funktioniert aber. Optimierung kommt später.

Könnte man das System auch für andere nutzen?

Ja, definitiv!

Nach meiner Einschätzung könnte man das System modular aufbauen und für andere Events/Vereine nutzen:

Potenzielle Anwendungsfälle:

• Sportverein: Turnier-Tickets
• Kulturverein: Theater-/Konzert-Karten
• Gastro: Event-Reservierungen
• Messen: Ticket + Badge-Druck

Was dafür nötig wäre:

• Admin-Panel für Multi-Event-Verwaltung
• Template-System für verschiedene Ticket-Designs
• Bessere Email-Queue (Background-Jobs)
• Offline-Scanner-App
• Stripe/PayPal Integration (optional)

SaaS-Potential?

Ehrlich gesagt: Ja, könnte man machen.

Kleine Vereine/Events zahlen aktuell wahnsinnige Gebühren an große Plattformen. Ein "Eventim für kleine Events" mit fairen Preisen (z.B. 1€ pro Ticket statt 10-15%) könnte funktionieren.

Aber: Das ist ein komplett anderes Business. Mal sehen. Erstmal muss unser Event im Juli laufen!

Fazit: Würde ich's wieder machen?

Absolut.

War es stressig? Ja.
Gab's Momente wo ich dachte "Warum hab ich zugesagt"? Auch ja.

Aber:

• Ich hab krass viel gelernt
• Das System funktioniert
• Der Verein ist begeistert
• Wir haben volle Kontrolle
• Und es hat 0€ laufende Kosten

Plus: Es macht einfach Spaß zu sehen wie aus "Klar kann ich das!" (ohne Plan) ein funktionierendes Live-System wird.

Empfehlung für andere

Solltest DU auch ein Ticketsystem bauen?

Kommt drauf an:

JA, wenn:

• Du Entwickler bist (oder werden willst)
• Du Lust auf ein Learning-Projekt hast
• Du volle Kontrolle willst
• Du Zeit hast (3-4 Wochen minimum!)
• Du Gebühren sparen willst

NEIN, wenn:

• Du schnell starten musst (heute buchen, morgen Event)
• Kein technisches Know-How
• Event ist riesig (10.000+ Tickets → lieber Profis)
• Keine Zeit für Support/Wartung

Für kleine bis mittlere Events (50-1.000 Tickets):
→ Selbst bauen kann sich absolut lohnen!

Für große Events:
→ Lieber etablierte Plattform nehmen.

Das System geht Live: Juli 2026

Wenn alles läuft wird im Juli 2026 das Gründungsfest der Faschingsgruppe Steigerwald e.V. stattfinden.

800 Tickets. Eine Band. Ein selbst gebautes Ticketsystem.

Dann sehen wir ob's hält.

Ich halte euch auf dem Laufenden!

Update folgt nach dem Event!