Ein Plakat abfotografieren statt ein Formular ausfüllen: das Event-Modul von Lokido

Ein Plakat abfotografieren statt ein Formular ausfüllen: das Event-Modul von Lokido

Vier Design-Entscheidungen aus dem Lokido-Event-Modul: vom kostenkontrollierten Plakat-Scanner bis zur cookiefreien Statistik, aus Entwicklersicht erklärt.

Dennis Schwenker-Sanders 3 Min. Lesezeit

Mit dem Launch von Lokido ist das Herzstück der Plattform live: das Event- und Gesuch-Modul für Anbieter. In diesem Beitrag zeige ich vier Design-Entscheidungen aus der Umsetzung, die aus meiner Sicht auch für andere Projekte interessant sind.

1. Der Plakat-Scanner: KI mit eingebauter Kostenbremse

Das größte Onboarding-Hindernis für Vereine ist Tipparbeit. Ein Sommerfest hat längst ein Plakat, aber niemand hat Lust, dieselben Daten nochmal in ein Formular zu übertragen. Der Plakat-Scanner löst das: Plakat fotografieren, Google Gemini Vision extrahiert Titel, Datum, Uhrzeit und Adresse, das Event-Formular ist vorausgefüllt. Der Scan legt bewusst nie selbst ein Event an, der Mensch bleibt die letzte Instanz.

Spannender als der KI-Aufruf selbst ist das, was davor passiert. Jeder Vision-Call kostet Geld, also läuft vor dem API-Request eine Kette günstiger Prüfungen: Bildvalidierung (Format, Größe, Mindestauflösung), ein perzeptueller Hash gegen Duplikate (90-Tage-Fenster), ein Kontingent pro Anbieter (Free 10, Pro 50 Scans pro Monat) und ein globales Monatslimit mit Kosten-Cap. Erst wenn alles durch ist, wird die API bezahlt.

2. Sichtbarkeit statt Blockade: das Tier-Modell als Datumslogik

Freemium-Modelle scheitern oft daran, dass sie Nutzer beim Anlegen blockieren und damit frustrieren. Lokido macht es anders: Beim Event-Anlegen wird niemand gestoppt, egal welcher Tarif. Der Free-Tier steuert stattdessen nur ein Datum: visible_from = starts_at - 14 Tage. Lange Vorlaufzeiten sind erlaubt, das Event erscheint einfach später. Die einzige harte Free-Grenze ist die maximale Laufzeit von 7 Tagen, die Saison-Dauerevents im Gratis-Tarif verhindert.

Alle öffentlichen Queries filtern zentral auf visible_from <= NOW(). Wer früher sichtbar sein will, löst einen Frühbucher-Credit ein, ausdrücklich als Opt-in und nie automatisch. Beide Stellschrauben, 14 Tage Vorlauf und 7 Tage Laufzeit, sind Bundle-Parameter, keine Magic Numbers im Code.

3. Anbieter-Statistiken ohne Cookies

Anbieter wollen wissen, ob sich ihr Eintrag lohnt. Gleichzeitig wollte ich kein Cookie-Banner-Monster bauen. Die Lösung: serverseitiges First-Party-Tracking mit fünf Metriken, Impression, Detail-Aufruf, Website-Klick, Kontakt-Klick, Share, gespeichert ausschließlich als aggregierte Tageszähler pro Event. Kein Personenbezug, keine Cookies, Deduplizierung über einen tagesrotierenden Hash, Bot-Filter über User-Agent-Listen.

Shares werden per sendBeacon gezählt, Website- und Kontakt-Klicks über eine Redirect-Route. Der Anbieter sieht trotzdem brauchbare Zahlen im Dashboard.

4. Moderation vor Veröffentlichung, mit KI als Vorfilter

Eine Familienplattform kann sich keine ungeprüften Inhalte leisten. Jeder Anbieter-Submit durchläuft deshalb eine Pre-Publication-Moderation: KI-gestützte Prüfung, ebenfalls Gemini, hinter einem eigenen Interface, bei Unsicherheit oder KI-Ausfall landet der Inhalt in der manuellen Queue statt online. Vertrauenswürdige Anbieter, Pro und Community-Pro in gutem Standing, bekommen ein schnelleres Routing.

Der Rahmen

Technisch ist Lokido eine Symfony-7.4-Anwendung auf Basis meines eigenen Lotse CMS, erweitert um ein Domänen-Bundle mit rund 20 Entities: Events, Listings, Gesuche, Abos, Credits, Rechnungen, Moderation. Frontend mit Twig, Tailwind 4 und Stimulus, API-first für eine spätere App. Zahlungen laufen über Mollie, inklusive lückenloser Rechnungsnummern nach § 14 UStG. Das Ganze läuft bewusst auf gewöhnlichem Shared Hosting: kein Docker, kein Node auf dem Server, keine Spezialumgebung.

Wenn du ein ähnliches Projekt planst, von der Plattform bis zum einzelnen KI-Feature mit Kostenbremse: Melde dich gern.

Artikel teilen: