Ticketsystem selbst gebaut: Von 0 auf Event-Plattform in 3,5 Wochen

Wie aus einer spontanen Zusage ein komplettes Event-Ticketsystem für 800 Gäste wurde — ohne Plan, aber mit viel Trial & Error.

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 — wir wollten 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, nimm Eventim. Für unser Vereinsfest mit 800 Gästen am Abend und insgesamt rund 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 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, E-Mail, 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 fünf verschiedene PDF-Generatoren getestet:

• TCPDF → zu aufgebläht
• mPDF → Probleme mit Logos
• Dompdf → langsam
• FPDF → Treffer.

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

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

Fails dabei:

• Logo zu groß → überlappt Text
• Text zu lang → geht über Seitenrand
• QR-Code falsch positioniert → unlesbar beim Scannen
• Encoding-Probleme bei Umlauten

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 / Bereits gescannt oder storniert → roter Screen

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

Bekannte Lücke: Offline-Funktionalität fehlt noch. Wenn am Event-Tag kein Netz ist… Für die Testphase erstmal egal — aber Learning für v2.0.

Das Admin-Dashboard

Was Veranstalter sehen müssen: Verkaufte Tickets, übrige Tickets, eingecheckte Gäste, Spenden — live, ohne Klick.

Der Red Button: Nach dem Event werden alle QR-Codes gelöscht (DSGVO). Alles andere in der DB wird verschlüsselt archiviert (Aufbewahrungsfrist für Buchhaltung). Excel-Export für die Buchhaltung mit allen Transaktionen als .xlsx.

Woche 3,5: Zahlungssystem & Email-Automation

Zahlungssystem: Vorkasse

Warum kein PayPal/Stripe? Ehrlich gesagt: Zu dem Zeitpunkt keine Ahnung von deren Bedingungen für Vereine. Plus: Vorkasse ist für Vereine simpler. Keine Gebühren außer normalen Bankgebühren.

Ablauf:

1. Kunde bestellt Ticket
2. Bekommt E-Mail: „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

Email-Flow (PHPMailer)

Bekanntes Problem: Der E-Mail-Versand ist langsam. Manchmal dauert es 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 E-Mail-Versand. Aber für den Start im April/Mai sollte das reichen.

Die größten Fails & Learnings

Fail #1: „Ich teste mal direkt live“

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

Ergebnis: Testdaten in der echten Datenbank. Chaos. Panik.

Fail #2: PDF-Generator-Hopping

Wie erwähnt: fünf 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 zwei- bis dreimal neu gebaut, weil die Architektur nicht passte.

Was hat das Ganze gekostet?

Was hätte Eventim gekostet? Ich habe gar nicht mehr nachgerechnet, weil das eigene System so gut lief. Aber typische Ticket-Plattformen nehmen etwa 10–15 % Gebühr pro Ticket plus eine Service-Fee für Käufer.

Eine Beispielrechnung:

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

Unser System:                    0 € laufende Kosten

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

Status Quo

Stand März 2026: System läuft, Testtickets erfolgreich generiert, Scanner-App funktioniert. E-Mail-Versand etwas langsam, wird noch optimiert.

Stand Juni 2026 (heute): Verkauf läuft, das Event am 18. Juli 2026 steht in einem Monat an. Ich aktualisiere diesen Artikel nach dem Event mit den echten Zahlen vom Tag.

Was wir erwarten: 800 Tickets für das Abendprogramm mit Band, rund 1.100 Gesamt-Besucher über den Tag, nachmittags offenes Programm ohne Ticket, abends Kartenbetrieb mit Geläanderäumung.

„Sehr geile Geschichte!“ — Vorstand Faschingsgruppe Steigerwald e. V.

Aus dem Verein kamen Fragen wie „Hast du das wirklich 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. E-Mail-Automation mit PHPMailer
6. Datenbank-Design für Ticketsysteme
7. Staging vs. Production

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. Fünf 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. E-Mail-Versand ist langsam? 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 nutzen: 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 E-Mail-Queue, Offline-Scanner-App und optional Stripe/PayPal-Integration.

SaaS-Potenzial?

Ehrlich gesagt: Ja, könnte man machen. Kleine Vereine 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 das Event im Juli durchgehen.

Fazit: Würde ich's wieder machen?

Absolut. War es stressig? Ja. Gab's Momente, in denen 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 (drei bis vier Wochen minimum)
• du Gebühren sparen willst

Nein, wenn…

• du schnell starten musst (heute buchen, morgen Event)
• du kein technisches Know-how hast
• das Event riesig ist (10.000+ Tickets — lieber Profis)
• du keine Zeit für Support und Wartung hast

Für kleine bis mittlere Events (50–1.000 Tickets) kann sich Selber-Bauen absolut lohnen. Für große Events: lieber etablierte Plattform.

Am 18. Juli 2026 ist das Event. 800 Tickets. Eine Band. Ein selbst gebautes Ticketsystem. Dann sehen wir, ob's hält. Update folgt nach dem Event.