FinTech-Backend für eine Versicherungs-App

Wie das Projekt gelaufen ist

Eine FinTech-Tochter im Versicherungs-Umfeld brauchte für mehrere Monate Backend-Verstärkung, die ab dem ersten Tag im Sprint mitschwimmt, ohne Onboarding-Vorlauf. Das passiert im FinTech häufiger als gewünscht: Eine Roadmap zieht an, das interne Team ist gebunden, externe Hände müssen die Differenz ausgleichen - und können nicht erst zwei Wochen lang Domain-Wissen aufbauen.

Konzern-Inkubator und Ausgründung in einem

Das Produkt war als Konzern-Startup im Venture-Builder-Arm der Versicherungs-Gruppe entstanden und wurde während unserer Beauftragung in eine eigenständige Gesellschaft überführt. Aus Code-Perspektive bedeutet das: Build-Pipelines, Identity-Schemas und Compliance-Vorgaben mussten weiterhin Konzern-Standard erfüllen, während Tempo und Sprint-Mechanik eines kleinen Produkt-Teams gefragt waren. Der Code lebte gleichzeitig in der Welt eines regulierten Versicherers und in der eines wachsenden FinTech-Produkts.

Genau in dieser Hybrid-Situation ist Erfahrungs-Mitarbeit Gold wert: Wer schon im Banking- und Versicherungs-Umfeld gebaut hat, kennt die Reibungen zwischen Konzern-IT und Produkt-Team und kann mit ihnen umgehen, ohne sie täglich neu erklärt zu bekommen.

Backend-Hände, die ab Tag eins liefern

Der Auftrag war scharf umrissen: bestehende Eloquent-/Doctrine-Schicht, klar dokumentierte API-Verträge gegen ein Mobile-Frontend, Vertrags-Logik mit nachvollziehbarem Audit-Trail. Wir konnten die ersten Tickets in der Woche eins ziehen, weil die Stack-Erfahrung aus Versicherungs- und Banking-Projekten der vorigen Jahre zugriffsbereit war. Onboarding-Tickets entfielen, die Sprint-Geschwindigkeit blieb konstant.

Konkret hieß das: PHP-Core-Services, REST-Endpoints gegen die Mobile-App, eine wachsende Domain rund um Verträge, Bewegungen und Audit-Events. Marco saß im täglichen Sprint-Standup mit, schrieb die Tickets selbst, lieferte Code mit Test-Abdeckung in den kritischen Pfaden. Wenn ein anderes Konzern-Team einen Mail-Versand-Adapter oder eine SSO-Integration nachzog, war eine kurze Abstimmung notwendig - keine wochenlange Einarbeitungs-Schleife.

Begleitung mit klarem Endpunkt

Über viele Monate, mit wechselndem Umfang, im Sprint-Takt des internen Teams. Das war keine offene Wartungs-Beziehung, sondern eine Liefer-Phase mit eindeutigem Cut-off: Wenn die Roadmap-Etappe abgeschlossen war, ging die Verantwortung wieder voll ans interne Team über. Diese Klarheit erleichtert beiden Seiten die Planung, weil keiner sich an die andere Seite bindet, ohne es zu wollen.

Aufgeräumte Code-Basis, dokumentierte Entscheidungen

Am Ende standen Code mit Test-Abdeckung in den kritischen Pfaden, ein paar Architecture Decision Records für die größeren Abzweigungen und kurze Übergabe-Notizen pro Modul. Für das Folge-Team gab es keinen Mystery-Code, sondern Implementierungen, die sich selbst erklären, weil die Entscheidungen daneben dokumentiert sind. Eine spätere Wiederaufnahme der Zusammenarbeit wäre jederzeit ohne Reibungs-Verlust möglich.

ADRs sind in regulierten Umfeldern doppelt wertvoll: Sie geben dem Folge-Team einen Einstieg in die Code-Geschichte und liefern gleichzeitig den Audit-Spur-Beleg, der bei einer internen Revision oder einer externen Prüfung verlangt wird. Wer warum welche Entscheidung getroffen hat, ist schwarz auf weiß nachlesbar - nicht Tribal-Wissen, das mit dem Vertragsende verschwindet.

Warum dieses Modell für FinTech-Phasen passt

FinTechs in der Wachstums-Phase brauchen oft genau zwei Dinge gleichzeitig: Liefer-Tempo und regulatorische Sauberkeit. Eine offene Werkvertrags-Beziehung ohne Endpunkt wird beidem nicht gerecht - sie ist administrativ teuer und verwischt die Verantwortungs-Grenzen zwischen intern und extern. Ein scharf umrissenes Mehr-Monats-Mandat mit klarem Cut-off macht die Phase plan- und prüfbar.

Für MARCODES ist das ein typisches Liefer-Profil im FinTech- und Versicherungs-Umfeld: Wir gehen in eine definierte Roadmap-Etappe, liefern in deren Takt und ziehen uns nach Übergabe geordnet zurück. Wir bauen kein Lieferanten-Abhängigkeits-Geflecht, sondern eine abgeschlossene Liefer-Phase, die das interne Team weiter selbst trägt.