Matchpoint: wo Athleten und Marken gemeinsam wachsen

Was gebaut wurde

Ein System of Record für Athlete-Brand-Sponsoring. Athleten erstellen Profile, Marken gründen Organisationen mit Teams, Partnerschaften durchlaufen einen definierten Lifecycle, von der ersten Kontaktaufnahme bis zum aktiven Sponsoring. Öffentliche Athleten-Verzeichnisse, teilbare Media Kits, ein Benachrichtigungssystem und eine Vendor-Admin-Oberfläche für Referenzdaten.

Vier deploybare Applikationen: API, Worker, Web-UI und Landing Page. Ein Monorepo, ein geteilter Typensatz, unabhängige Deployments. Die Domain hatte bisher keine Software: alles lief über E-Mails, DMs und Excel.

Die Rahmenbedingung

Das System wird die Basis für alles Weitere: Metriken, Content-Aggregation, Federation-Integration, Service-Provider-Anbindung. Was jetzt an Architektur steht, muss tragen. Nicht für drei Monate, sondern für die nächsten Jahre.

Die Entscheidung war deshalb nicht, möglichst schnell etwas zu zeigen. Sondern etwas zu bauen, das man verantworten kann. Architekturelle Reinheit war kein Luxus, sondern die Bedingung dafür, dass Geschwindigkeit später nicht zum Problem wird.

Die Architektur

Core-First, Ports & Adapters. Die gesamte Domänenlogik lebt in einem eigenen Package, ohne NestJS, ohne Prisma, ohne Supabase. Framework-agnostisch, testbar, portabel. Das API-Layer adaptiert, das Core-Layer entscheidet.

Autorisierung über ABAC mit CASL, nicht RBAC. Policies evaluieren Kontext: Benutzer, Organisation, Ressource, Rolle. Ein Benutzer kann gleichzeitig Vendor, Brand-Admin und Athlet sein: die Regeln bleiben konsistent. CASL-Policies werden im Core definiert, im API-Layer durchgesetzt, in der Datenbank durch RLS als zusätzliche Sicherheitsschicht ergänzt.

Für zuverlässige Side Effects ein Outbox Pattern: Partnerschaft-Statuswechsel erzeugt einen Outbox-Eintrag in derselben Transaktion. Ein Worker-Service pollt und verarbeitet asynchron: Benachrichtigungen, Events, externe Aktionen. Nicht nur auf dem Whiteboard, sondern in Produktion validiert.

Was die Geschwindigkeit ermöglicht hat

40 Features in vier Wochen klingt nach Prototyp. War es nicht.

Spec-Driven Development: jedes Feature hat eine Spec, wird hinterfragt, dann implementiert. Domain Docs entstehen während der Implementierung, nicht danach. Die Spec definiert was gebaut wird, die Domain Doc hält fest was steht. Kein Rework durch Missverständnisse, weil die Fragen vorher beantwortet werden.

Das Monorepo eliminiert Koordination. Geteilte Types zwischen Core, API und Web: wenn sich ein Contract ändert, bricht der Build sofort. Keine Versionierung, keine Publish-Zyklen, keine Integrationsprobleme.

Die Disziplin, nichts ins Core-Layer zu lassen was dort nicht hingehört, hat mehr Zeit gespart als jede Abkürzung es gekonnt hätte.

Was daraus bleibt

Wer ein System of Record baut, baut Fundament. Die Architektur muss am ersten Tag stimmen, nicht weil sie perfekt sein muss, sondern weil sie die Entscheidungen von morgen nicht blockieren darf. Portabilität war keine Übung, sondern eine bewusste Entscheidung: Supabase als Infrastruktur, nicht als Gefängnis. Prisma-Migrationen als reines SQL. Kein Vendor-Lock-in, der später teuer wird.

Und die Geschwindigkeit kam nicht trotz der Disziplin, sondern wegen ihr.