Creator Marketing Platform

Creator-Marketing-Plattform — öffentliche Site, Kunden-Dashboard und Admin-Konsole

Wir haben die vollständige technische Plattform für einen regionalen Creator-Marketing-Service geliefert: ein Multi-Tenant-SaaS, das Endkunden mit einem aggregierten Katalog von Engagement-Services auf dreizehn sozialen Plattformen verbindet. Unser Lieferumfang umfasste die gesamte Engineering-Oberfläche — Java-Spring-Boot-Backend, Next.js-16-Kunden-Dashboard, eigenständige Admin-Konsole, Zahlungs-Infrastruktur, automatisierte Refund-Verarbeitung und einen Provider-Sync-Layer, der einen sich kontinuierlich verändernden Upstream-Katalog von über 1.200 einzelnen Services normalisiert und bepreist. Die Plattform wird von einem externen Auftraggeber für den GUS-Markt betrieben. Die operative Compliance mit den Nutzungsbedingungen der jeweiligen sozialen Plattformen, mit Werberichtlinien und mit den Regeln der Zahlungsdienstleister liegt vollständig beim Betreiber; unsere Rolle bestand darin, die spezifizierte technische Infrastruktur zu liefern — audit-fähig und für den Dauerbetrieb durch Operatoren ausgelegt.

Für vergleichbare Plattform-Engagements siehe Backend-Entwicklung und Startup & MVP Development.

Entscheidungskontext

Der Auftrag verband eine schnelllebige, kundennahe Oberfläche mit einer Backend-Steuerung auf Operator-Niveau. Beide Seiten mussten gleichzeitig live gehen, dasselbe Datenmodell teilen und häufige Provider-Katalogänderungen überstehen, ohne laufende Kundenbestellungen zu beschädigen.

Das Projekt als reinen Storefront oder als Back-Office-Tool zu behandeln, hätte das falsche System produziert. Wir haben es als eine einzige Plattform mit drei klar abgegrenzten Oberflächen modelliert — öffentliche Marketing-Site, authentifiziertes Kunden-Dashboard und Admin-Operations-Konsole — die ein gemeinsames kanonisches Service-Register und eine gemeinsame Pricing-Engine teilen.

Wesentliche Risiken in der Entscheidungsphase:

Ein volatiler Upstream-Katalog (über 1.200 Services, wöchentliche Änderungen), der kundenseitige Preise und Limits beschädigen kann.
Zahlungsintegration mit regionalen Zahlungsdienstleistern und automatisierte Refunds ohne manuellen Reconciliation-Aufwand.
Mehrrollige Oberfläche — Kunde, Support-Mitarbeiter, Superadmin — mit strikter rollenbasierter Zugriffssteuerung, ohne Operatoren auszubremsen.
Operator-Pflichten gegenüber Plattform-Nutzungsbedingungen und Verbraucherschutzrecht liegen außerhalb unseres Lieferumfangs, sind aber von der technischen Plattform aus sichtbar — das System musste diese Anforderungen ausdrückbar und nachvollziehbar machen.

Wir haben die Plattform um ein einziges kanonisches Service-Register, eine Pricing-Engine mit Override-Funktion auf jeder Ebene und ein Audit-Log für jede zustandsverändernde Aktion herum entworfen — so kann der Betreiber Zahlungsdienstleistern, Providern und Behörden lückenlos nachweisen, was berechnet, nachgefüllt, erstattet und an wen gerichtet wurde.

Plattform-Umfang & Funktionen

Das System deckt den gesamten Bestell-Lebenszyklus ab — von der öffentlichen Discovery über Zahlung, Erfüllung, Refund bis hin zum Reporting. Drei koordinierte Oberflächen teilen sich ein Backend.

Wichtige Funktionen:

Öffentliche Marketing-Site mit plattformspezifischen Landing-Pages und einem Servicekatalog mit 9 Kategorien × 13 Plattformen (~50 finale Pricing-Seiten, server-gerendert, Sitemap-indexiert).
Kunden-Dashboard mit dreistufigem Bestellfluss, Guthaben-Aufladung, Transaktionshistorie, Refill-Anfragen und einem Auto-Boost-Regel-Editor für wiederkehrende Veröffentlichungen.
Admin-Operations-Konsole mit globalem Markup, service-spezifischen Preis-Overrides, Provider-Sync, Bestell-Eingriffen (Stornierung, Kompensation, Refund), Nutzerverwaltung und vollständigen Audit-Trails.
Provider-aggregierender Katalog-Layer, der Upstream-Listings einliest, Plattform/Service/Plan normalisiert, Pricing-Regeln anwendet und den Katalog der Kunden-Site über eine einzige Read-API zur Verfügung stellt.
Automatisierte Zahlungs- und Refund-Pipeline, abgestimmt auf regionale Zahlungsdienstleister, mit idempotenten Kompensations-Flows und Human-Review-Gates für nicht-triviale Fälle.

Die Plattform erlaubt dem Betreiber, den Katalog ohne Engineering-Aufwand zu skalieren: neue Provider, neue Services und neue Pricing-Regeln werden über die Admin-Konsole konfiguriert, die kundenseitige Site rendert die betroffenen Seiten beim nächsten Request neu.

Creator-Marketing-Plattform — öffentliche Site, Kunden-Dashboard und Admin-Konsole - Image 1

1 / 57

Architektur

Backend — Java 21 mit Spring Boot 3, PostgreSQL, Redis und einer Job-Queue für asynchronen Provider-Sync, Refund-Verarbeitung und Order-Polling. Strikt typisierte REST-API mit rollenbasiertem Zugriff, durchgesetzt auf Controller-Ebene; Audit-Interceptors pro Endpoint erfassen jeden zustandsverändernden Aufruf. Frontend — Next.js 16 (App Router, Turbopack) und React 19 mit TypeScript, sowohl für die Marketing-Site als auch für das Dashboard. Server-gerenderte Marketing-Seiten für SEO; client-seitiges Dashboard mit Server Actions und React Query für Live-Daten. Die Admin-Konsole ist ein eigenständiges Route-Segment hinter einem Authentifizierungs-Guard. Katalog & Pricing — ein einziges kanonisches Register bildet jeden Upstream-Provider-Service auf ein (Plattform, Service-Art, Plan)-Tupel ab. Die Pricing-Engine akzeptiert globalen Markup, service-spezifische Overrides, Festpreis-Pakete und Refill-Multiplikatoren; Quotes werden serverseitig berechnet und vor der Anzeige im Checkout signiert, sodass Manipulationen auf Client-Seite nicht zu einer Diskrepanz mit der tatsächlichen Belastung führen können.

Operator-seitige Compliance-Oberfläche

Die Plattform selbst trifft keine Annahme über ein bestimmtes regulatorisches Regime — diese Entscheidung liegt beim Betreiber. Wir haben die technischen Primitive geliefert, die der Betreiber benötigt, um die für seinen Zielmarkt geltenden Vorschriften einzuhalten:

Vollständiges Audit-Log jeder Belastung, jedes Refunds, jeder Aufladung und jedes Admin-Overrides, abfragbar nach Nutzer, nach Bestellung und nach Zeitfenster.
Idempotente Zahlungs- und Refund-Operationen, geschlüsselt über externe Payment-IDs, um Doppelbelastungen oder Doppelrefunds zu verhindern.
Service-spezifische ToS-Flags und Operator-konfigurierbare Disclaimer, die im Checkout angezeigt werden, wenn ein Provider dies verlangt.
Account-Löschungs-Flow mit definiertem Aufbewahrungsfenster für Daten, die der Betreiber gesetzlich aufbewahren muss.
Rollenbasierte Zugriffssteuerung mit klar definierter Superadmin-/Admin-/Support-Hierarchie und einem separaten Audit-Feed für sensible Aktionen.

Welche Pflichten in seinem Markt gelten, entscheidet der Betreiber. Die Plattform macht diese Entscheidungen sichtbar, konfigurierbar und überprüfbar, statt sie über die gesamte Geschäftslogik zu verstreuen.

Engineering-Highlights

Der Provider-Sync-Layer verarbeitet einen Upstream-Katalog, der wöchentlich driftet — Services werden umbenannt, abgekündigt, neu bepreist oder in neue Varianten gespalten. Wir haben einen deterministischen Matcher gebaut, der jede Upstream-Position über ein parametrisierbares Regelwerk auf (Plattform, Service-Art, Plan) abbildet, sodass über 90 % der Katalogänderungen ohne manuelle Eingriffe durchlaufen; nur Edge Cases landen in der Admin-Review-Queue. Die Pricing-Engine trennt den Upstream-Preis (Provider-Kosten) vom Kundenpreis (Operator-Markup) und erlaubt dem Betreiber Overrides auf jeder Ebene — global, pro Plattform, pro Service oder pro Bundle. Quotes sind signiert und kurzlebig, sodass der im Checkout angezeigte Preis cent-genau dem Belastungsbetrag entspricht. Die Admin-Konsole ist auf nachhaltigen Operator-Einsatz ausgelegt: durchsuchbarer Katalog (1.240 Einträge), tastatur-freundliche Modals für Pricing- und Guthaben-Anpassungen, optimistic UI für risikoarme Aktionen und ein expliziter Bestätigungsdialog für alles, was Geld oder Status bewegt.

Projekt-Kontext

Es handelte sich um eine Single-Vendor-Lieferung: vom initialen Scoping über Architektur, vollständige Implementierung, Infrastruktur-Setup bis hin zur Übergabe an den Betreiber. Die Screenshots in dieser Fallstudie wurden in einer Staging-Umgebung mit englischen Mock-Daten aufgenommen; der produktive Einsatz erfolgt unter einer eigenständigen Marke des Auftraggebers für ein regionales GUS-Publikum. Wir präsentieren diesen Case als Engineering-Portfolio-Stück — um zu illustrieren, wie wir Multi-Surface-SaaS-Plattformen strukturieren, Operator-Anliegen von der Produktoberfläche trennen und Backend-Primitive entwerfen, die es Operatoren ermöglichen, Upstream-Veränderungen aufzufangen, ohne das kundenseitige Erlebnis zu beeinträchtigen.

Was wir geliefert haben

Java-Spring-Boot-Backend (REST-API, PostgreSQL, Redis, Job-Queue, Audit-Middleware).
Next.js-16-Marketing-Site mit plattformspezifischen Landing-Pages, Servicekatalog und SEO-optimierten Service-Detailseiten.
Next.js-16-Kunden-Dashboard: dreistufiger Bestellfluss, Guthaben, Transaktionen, Support, Auto-Boost-Regeln.
Admin-Operations-Konsole: Katalog mit Provider-Sync und Pricing-Regeln, Nutzer, Bestellungen, Zahlungen, Refunds, System-Einstellungen.
Provider-aggregierende Katalog-Aufnahme mit deterministischem Matcher und Admin-Review-Queue.
Pricing-Engine mit Overrides auf globaler, Plattform-, Service- und Bundle-Ebene; signierte Quotes für Checkout-Integrität.
Zahlungsintegration, abgestimmt auf regionale Zahlungsdienstleister, plus idempotente automatisierte Refunds.
Rollenbasierte Zugriffssteuerung mit Audit-Trail für sensible Aktionen.
Zweisprachige Inhaltsoberfläche (Hauptsprache des Betreibers plus englische Spiegelversion für Portfolio-Screenshots).

Ergebnis

Der Betreiber ist mit einer komplett von einem einzigen Lieferanten gebauten Plattform live gegangen — sie deckt öffentliche Discovery, authentifizierte Bestellung und vollständige operative Werkzeuge ab — und kann den Katalog jetzt erweitern, Preise anpassen und Provider-Veränderungen auffangen, ohne Engineering-Beteiligung. Für uns ist dieser Case eine Referenz dafür, wie wir Multi-Surface-SaaS angehen, bei denen der Operator-Alltag genauso wichtig ist wie die kundenseitige UX: ein kanonisches Modell, drei koordinierte Oberflächen, jeder Statuswechsel überprüfbar. Alle in den Screenshots referenzierten Drittplattform-Namen sind Eigentum ihrer jeweiligen Inhaber. Die Plattform selbst wird von einem externen Auftraggeber betrieben; wir haben ausschließlich das Engineering geliefert. Die Screenshots wurden in einer Staging-Umgebung mit englischen Mock-Daten aufgenommen.