Make oder Modify?

Strategische Entscheidungsgrundlage für den Vorstand.
Fundraising-Software-Plattform der Sozialbank.
Köln, April 2026

Board Meeting Strategische Entscheidung

Ausgangslage & Vorgehen

Arbeitsauftrag

Die Sozialbank hat die Weichen gestellt: Der Fundraising-Service soll langfristig leistungsfähig, unabhängig und zukunftssicher aufgestellt werden. Railslove wurde beauftragt, die strategischen Optionen zu bewerten: eigenständige Neuentwicklung (Make) oder Modernisierung des Bestands (Modify).

📋 Ursprünglicher Projektauftrag:
Projektskizze "Fundraising-Service" →

Ergebnis dieser Vorlage

Klare Entscheidungsgrundlage für den Vorstand — mit Kostenvergleich, Risikoabwägung und konkreter Empfehlung.
Interaktiver Prototyp zur Veranschaulichung des Make-Konzepts: sozial-fundraise-hub.lovable.app

Vorgehen

01

Analyse der bestehenden Plattform (technisch, funktional, strategisch)

02

Interviews & Abstimmung mit internen Stakeholdern

03

Kriterienbasierte Bewertung beider Optionen (Entscheidungsmatrix)

04

Marktrecherche & Kostenkalkulation auf Basis marktgängiger Tagessätze inkl. Sozialbank-Vollkosten


Make oder Modify?

Kriterienbasierte Entscheidungsgrundlage

Die folgende Matrix bewertet beide strategischen Optionen anhand der für uns relevanten Entscheidungskriterien.
Make ist unsere klare Empfehlung und die Matrix zeigt, warum.

Die Sozialbank erweitert damit ihr Leistungsverständnis: von rein finanzieller Infrastruktur hin zu einem Enabler für operative Wertschöpfung ihrer Kund:innen — NGOs starten Kampagnen im eigenen Namen, als White-Label-Angebot der Bank.

(📄 Methodische Grundlagen & Detailbewertungen:
- Entscheidungs-Matrix Analyse →
- Make / Modify / Cooperate – Analyse & Scoring → )

Technisches Set-Up: Make

Architektur der Neuentwicklung

Unsere empfohlene Make-Lösung basiert auf einer modernen, skalierbaren Cloud-Architektur, die maximale Flexibilität und Kontrolle bietet. Sie ist speziell auf die Anforderungen der Fundraising-Software-Plattform zugeschnitten.

Diese Architektur gewährleistet strategische Souveränität und ermöglicht eine phasenweise Entwicklung bis zur vollständigen Plattform.

Wichtige Stack-Entscheidungen

  • Frontend: Frontend/Full-Stack: Next.js (React-basiertes Full-Stack-Framework) – bewährt, breite EntwicklerInnen-Verfügbarkeit.
  • Backend: Node.js oder Ruby on Rails – pragmatisch, schnell skalierbar.
  • Datenbank: PostgreSQL – robust, DSGVO-konform, On-Premise oder managed (AWS/Azure).
  • Hosting: Hosting: AWS – ISO 27001, DSGVO-konform, §25b KWG-konform (Auslagerungsanforderungen).
  • Zahlungsintegration: Stripe (kritischer Pfad), PayPal und Wero.
  • Sozialbank-spezifisch: SEPA-Lastschrift via EBICS-Direktanbindung – einzigartiger USP.
  • Mehrmandantenfähigkeit: Architektur von Beginn an auf strikte Datentrennung und White-Label-Fähigkeit je Kundenorganisation ausgelegt.

Sicherheit & Compliance

Ein besonderer Fokus liegt auf Sicherheit und der Einhaltung regulatorischer Anforderungen:

  • Nutzung der bestehenden PCI-DSS-Infrastruktur der Sozialbank.
  • DSGVO-konformes Datenmodell, wobei Spenderdaten ausschließlich bei Sozialbank verbleiben.
  • Ein verpflichtender Pentest vor dem Go-Live zur Sicherstellung der Systemintegrität.

Technisches Set-Up: Modify

Architektur-Skizze: Weiterentwicklung Bestandssystem (Modify)

Die Analyse der bestehenden Architektur zeigt die Herausforderungen und Risiken einer Weiterentwicklung der aktuellen Fundraising-Plattform. Die vorliegende Struktur erfordert erhebliche Anpassungen, um moderne Anforderungen zu erfüllen.


Strukturelle Risiken bei Modify

Legacy-.NET-Architekturgrenze

Neue Features erfordern tiefe Eingriffe in gewachsenen Code, was die Entwicklung verlangsamt und das Fehlerrisiko erhöht.

Begrenzte Produktexpertise

Think Beyond verfügt nicht über ausreichende Produktexpertise für eine strukturierte Feature-Entwicklung, was zu suboptimalen Lösungen führen kann.

Veraltete Designentscheidungen

Technische Schulden akkumulieren weiter, ohne einen klaren Pfad zur Modernisierung und Innovation.

Kein klarer Migrationspfad

Ohne einen Neustart gibt es keinen effizienten Weg zu einer modernen Architektur, was langfristig die Wettbewerbsfähigkeit gefährdet.

Modifikationsumfang (Mindestanforderungen)

1

UI-Redesign (vollständig)

Das Frontend muss komplett überarbeitet werden, um moderne Erwartungen der NutzerInnen zu erfüllen und die Usability zu verbessern.

2

CRM-Integration (Neuentwicklung)

Eine Neuentwicklung der CRM-Integration ist notwendig, um SpenderInnen-Daten effizient zu verwalten und Marketingaktivitäten zu optimieren. Besonders relevant für kleine und mittlere NGOs ohne eigenes CRM-System.

3

SEPA/EBICS-Anbindung (Erweiterung)

Bestehende Schnittstellen müssen erweitert werden, um den aktuellen Anforderungen für SEPA-Lastschriften und EBICS gerecht zu werden.

4

Zahlungsmethoden-Update

Integration neuer Zahlungsmethoden wie Wero und Modernisierung bestehender Payment-Flows ist unerlässlich.

5

Pentest und Sicherheits-Audit

Ein umfassender Sicherheitstest ist zur Risikominimierung und Gewährleistung der Compliance notwendig.

🔍 Technische Grundlage: Tech Due Diligence – Net.Tool XXL →

Kostenvergleich Make

Aufbau & Betrieb (5 Jahre, marktgängige Kalkulation)

Kalkulationsbasis:

  • Externe Entwicklungskosten: marktübliche Tagessätze für ein Systemhaus
  • Entwicklung / UX: 1.400–1.800 €/Tag brutto
  • Projektleitung/Architektur: 1.650–2.100 €/Tag brutto
  • DevOps/Security: 1.400–1.800 €/Tag brutto
  • Interne Kosten bei der Sozialbank: Vollkosten 112 T€/Jahr pro Stelle = ~431 €/Tag (bei 260 AT/Jahr)
  • Projektbeteiligung während Aufbau: anteilig nach Aufwand
  • Neue Stellen im Betrieb: als Jahresvollkosten ausgewiesen

Phase 0 — Setup & Infrastruktur (Monat 1–2)


Phase 1 — MVP (Monat 3–8)


Phase 2 — Zweite Iteration (Monat 9–12)


Parallelbetrieb .NET-Plattform (Monat 1–12)


Laufender Betrieb & Weiterentwicklung (ab Go-Live)

Neue Sozialbank-Stellen im Betrieb (Vollkosten 112 T€/Stelle/Jahr):

⚠️ Hinweis Product Owner: Der ausgewiesene Ansatz von 112 T€/Jahr entspricht der internen Vollkostenbasis der Sozialbank. Marktübliche Vollkosten für erfahrene Product Owner liegen bei 120–140 T€/Jahr. Die Rolle ist geschäftskritisch: Sie verantwortet Produktstrategie, Kundennähe und interne Expertise. Eine Unterbesetzung oder -vergütung gefährdet den zentralen Mehrwert der Make-Option.


Personalaufbau: Jahr 1 zunächst 2 Vollstellen + 1 halbe Stelle (224 T€). Ab Jahr 2: 3 Vollstellen (336 T€) + anteilig Weiterentwicklung intern (~38 T€), also konstant ~374 T€ interne Personalkosten/Jahr.

5-Jahres-Gesamtübersicht Make (marktgängig, inkl. Sozialbank-Vollkosten)

Kostenvergleich Modify

Aufbau & Betrieb (5 Jahre, marktgängige Kalkulation)

Besonderheit: Der Modify-Aufwand ist aufgrund der Legacy-.NET-Komplexität mit höherer Unsicherheit behaftet. Die Kalkulation enthält daher Risikozuschläge.

Kalkulationsbasis intern: Vollkosten 112 T€/MA/Jahr = ~431 €/Tag (260 AT/Jahr)

Modify-Phase — Redesign & Feature-Aufbau (Jahr 1 + 2)


Parallelbetrieb .NET-Plattform (Monat 1–18)


Laufende Stellen im Betrieb Modify (Vollkosten 112 T€/Stelle/Jahr)


Laufender Betrieb & Weiterentwicklung Modify (ab Go-Live)


5-Jahres-Gesamtübersicht Modify (marktgängig, inkl. Sozialbank-Vollkosten)

Hinweis: Die erhebliche Bandbreite bei Modify spiegelt das strukturelle Risiko der Legacy-.NET-Architektur wider. Kostenüberschreitungen von 30–50% bei Legacy-Modernisierungsprojekten sind marktüblich dokumentiert (Referenz: Standish Group Chaos Report, Gartner). Interne Personalkosten: 112 TEUR Vollkosten/Stelle/Jahr gemäß Sozialbank-Kalkulation.

Direktvergleich: Make vs. Modify (5 Jahre)

TCO-Gesamtvergleich
Marktgängige Kalkulation inkl. Sozialbank-Vollkosten (112 TEUR/MA/Jahr)

Die Aufbaukosten bei Make liegen ~152k höher. Dieser Unterschied relativiert sich durch:

  • Früherer Go-Live um 6–12 Monate (= frühere Umsatzrealisierung)
  • Geringeres Risiko von Kostenüberschreitungen (Legacy-Projekte: +30–50% häufig)
  • Niedrigere externe Betriebskosten ab Jahr 3 durch saubere Architektur
  • Vollständige strategische Kontrolle — keine Abhängigkeit von Think Beyond

Beide Optionen liegen bei ~4,2 Mio. € TCO über 5 Jahre. Make ist teurer im Aufbau, günstiger und risikoärmer im Betrieb.

Zeitliche Realität: Make vs. Modify

Von Kickstart bis Vollplattform

Empfehlung: Make

Strategische Autonomie schlägt vermeintliche Schnelligkeit

Beide Optionen wurden fair und auf Basis marktgängiger Kosten bewertet. Make überzeugt in den strategisch entscheidenden Kriterien.
Ziel: 50 % Marktanteil bis 2029, Verdopplung auf 3.200 Spendenkonten — das erfordert ein eigenes, unverwechselbares Produkt.
Die folgenden Argumente sind ausschlaggebend:

Datensouveränität

Eine Neuentwicklung legt das Datenmodell von Beginn an sauber und DSGVO-konform an — ohne gewachsene Altstrukturen. Compliance-Anforderungen (DSGVO, BaFin, Barrierefreiheit) werden intern gesteuert und können eigenständig priorisiert werden.

Roadmap-Autonomie

Bei Modify bremsen technische Schulden jede neue Funktion — Eingriffe in den Legacy-Stack sind aufwendig und fehleranfällig. Make startet ohne Altlast: Features werden schneller, sauberer und kosteneffizienter umgesetzt. Die Velocity steigt mit der Zeit, statt zu sinken.

Bankspezifische Infrastruktur-USPs

Kostenlose SEPA-Lastschriften, EBICS-Direktanbindung und PCI-DSS-zertifizierte Infrastruktur sind einzigartige Assets der BFS — kein Kooperationspartner kann das replizieren oder als Differenzierungsmerkmal einsetzen.

White-Label & Enabler-Positionierung

NGOs agieren unter ihrer eigenen Marke. Die Sozialbank wird zum unsichtbaren Infrastruktur-Partner — und erweitert ihr Leistungsverständnis von reiner Finanzinfrastruktur hin zur operativen Wertschöpfungsplattform ihrer Kund:innen.

Zukunftsfähige Architektur

Eine Neuentwicklung auf modernem Cloud-Stack ist von Beginn an skalierbar, wartungsarm und erweiterbar — ohne die strukturellen Grenzen eines gewachsenen Legacy-Systems. Modify bedeutet eine dauerhafte Investition in .NET-Altcode. Make schafft eine Grundlage, die mit den Anforderungen der Sozialbank wächst.

Clickdummy

Seht selbst — der Dummy ist bereit

Der interaktive Clickdummy zeigt den aktuellen Stand des Make-Konzepts:
User Flows, zentrale Funktionsbereiche und die geplante UX für NGO-Nutzer.

Der Clickdummy deckt folgende Bereiche ab:
Spendenerfassung, Kampagnenmanagement, Berichtswesen und das Nutzerverwaltungskonzept.

Danke.

Für eure Zeit, euer Vertrauen und die gemeinsame Entscheidung für die richtige strategische Richtung.


Railslove GmbH | Liane Kirschner, Jan Kus | April 2026