RE-Card

Recklinghausens Innenstadt stand vor einem Problem, das viele mittelgroße Städte kennen: Der lokale Handel verlor Sichtbarkeit und Kundenbindung gegenüber dem Online-Handel. Erschwerend kam hinzu, dass die vorhandene Lösung — eine centergebundene Geschenkkarte des Palais Vest — auf einen einzigen Akteur beschränkt war und die Händler der umliegenden Altstadtquartiere außen vor ließ. Die RE-Card sollte diese Zerspaltung verbinden: ein stadtweites Programm, das alle Innenstadt-Quartiere unter einer digitalen Marke vereint, Endkunden über eine mobile App erreichbar macht und Händlern erstmals eine einheitliche digitale Präsenz bietet.

Fachlich war das System deutlich dichter als ein klassischer Angebots-Aggregator: Es verband ein CMS-gesteuertes Web-Portal mit einer nativen Cross-Platform-App, einem moderierten Community-Bereich für nutzergenerierte Inhalte und Newsletter-Anmeldungen. Zum Launch waren rund 150 Läden und Restaurants integriert — das Projekt wurde in regionalen Medien als konkretes Instrument der Innenstadtstärkung wahrgenommen.

Für Händler bedeutete die Plattform erstmals eine einheitliche digitale Präsenz im Stadtkontext. Kunden fanden Angebote, Events und Aktionen aller teilnehmenden Quartiere gebündelt an einem Ort — und konnten selbst entdeckte Tipps und lokale Angebote über den Community-Bereich direkt in der App einreichen.

Ich war in diesem Projekt als Entwickler und technischer Berater eingebunden — ohne die übergeordnete Projektverantwortung, aber mit klarer End-to-End-Verantwortung für definierte Teilbereiche. Ich protokollierte Abstimmungen mit dem Projektteam, verfolgte Entwicklungsfortschritte und offene Punkte aktiv nach und koordinierte die Qualitätssicherung.

Federführend legte ich die Architektur der Plattform-Synchronisation zu Firebase aus: Konzeption des Synchronisations-Microservices, Datenschema-Design und Umsetzung der Batch-Transaktionspipeline. Gleiches gilt für mehrere Teilmodule der Backoffice-Software für Händler — von der Konzeption über die Umsetzung und das Testing bis zur Bereitstellung verantwortete ich diese Komponenten vollständig. Ergänzend übernahm ich die iOS-Auslieferung sowie den SEO- und Performance-Audit der Webpräsenz.

Systemintegration zweier divergenter Nutzermodelle: Das Web-Backend und Firebase Auth verfolgen grundlegend unterschiedliche Authentifizierungsmodelle — ein direktes Mapping hätte entweder die Datenkonsistenz gefährdet oder durch eine externe Cloud-Auth-Integration laufende Kosten je Anmeldung erzeugt. Um beide Systeme ohne redundante Nutzerverwaltung zu verbinden, wurde ein eigener Auth-Flow mit gerätebezogenem User-Token konzipiert, der Web-Sitzungen und App-Identitäten konsistent verknüpft.

Skalierbare Datensynchronisation unter Cloud-Limits: Hunderte Händler mit ihren Angeboten mussten aus dem Web-Backend in Firebase Firestore überführt werden — bei gleichzeitiger Einhaltung des 500-Operationen-Limits je Batch-Transaktion und der Paginierungsgrenze von 300 Dokumenten je API-Antwort. Der entwickelte Microservice ruft den Datenbestand rekursiv über nextPageToken-Paginierung ab, formuliert Lösch- und Schreibtransaktionen und überträgt diese in atomaren 500er-Batches. Das Ergebnis ist ein Sync-Prozess, der ohne manuelle Eingriffe konsistente Daten in der Cloud hält.

Performance und Core Web Vitals: Das eingesetzte Web-Backend liefert standardmäßig unkomprimierte CSS/JS-Bundles ohne optimierte Cache-Header — bei einem stadtweiten Programm mit breiter Nutzerbasis unmittelbar relevant für Sichtbarkeit und Ladeverhalten. Ein vollständiger SEO- und Performance-Audit der Webpräsenz identifizierte die wesentlichen Schwachstellen; Anzahl und Größe der geladenen Assets wurden reduziert und serverseitige Cache-Header für statische Ressourcen implementiert, was zu messbaren Verbesserungen bei Largest Contentful Paint und First Contentful Paint führte.

Proof-of-Concept für ein QR-basiertes Tischbestellsystem: Das Projektteam evaluierte die Erweiterung der Plattform um ein QR-gestütztes Echtzeit-Tischbestellsystem für Gastronomie-Partner. Im Rahmen eines PoC wurden das Datenschema für Menüverwaltung und Bestellkommunikation entworfen sowie die technische Machbarkeit der Stack-Entscheidung bewertet. Das System wurde konzipiert und im PoC getestet, aber nicht produktiv ausgerollt.