Die Vorführung erfolgt oft live: Ein Partner öffnet einen Code-Assistenten, generiert in zwanzig Minuten den Prototyp eines Monitoring-Dashboards, und der Raum ist überzeugt. Der Kostenvoranschlag im Kopf ist fertig: ein Entwickler, ein LLM, erledigt.

Die Vorführung ist wahr. Der Kostenvoranschlag ist falsch. Denn was der Zwanzig-Minuten-Prototyp nicht zeigt, ist alles, was einen Prototyp von einer Software im Produktivbetrieb einer Fondsgesellschaft trennt: die Administration der Anwendung, das Rechtemanagement, die Sicherheit, die Backups, die Compliance, die Übersetzung eines vagen Bedarfs in eine Spezifikation und dann in getesteten Code, und eine Roadmap, die nie stillsteht, weil das Geschäft nie stillsteht. Die Software-Engineering-Forschung sagt es seit vierzig Jahren: Wartung und Weiterentwicklung machen nach den klassischen Studien 40 bis 80% der Gesamtkosten einer Software über ihren Lebenszyklus aus, weit mehr als die Erstentwicklung [1]. LLMs haben die Kosten der ersten Version geteilt. Die Kosten der folgenden fünf Jahre haben sie nicht geteilt.

Dieser Leitfaden spielt in zwei Akten: zuerst die Rechnung, heute, mit Zahlen auf dem Tisch. Dann die Projektion auf zwei Jahre, dort, wo die Antwort komplizierter wird und die eigentliche Frage nicht mehr die ist, die man vermutet.

Erster Teil: die Rechnung von heute

Rechnen wir nach

Nehmen wir eine mittelgroße Fondsgesellschaft, 15 bis 30 Personen, die beschließt, ihr Verwaltungstool intern zu bauen (Beteiligungs-CRM, Reporting, Monitoring). Modellieren wir ehrlich, was "Make" kostet, in Arbeitgeber-Vollkosten, Frankreich 2026, mit bewusst vorsichtigen Annahmen.

Dem gegenüber das Abonnement einer spezialisierten Marktlösung, bei vergleichbarem Umfang: kein bloßes CRM, sondern die komplette Plattform, die der Entwickler hätte bauen sollen, CRM, Reporting, Portale, Daten:

Und halten wir bei der Symmetrie inne, denn sie ist jede Demonstration wert: Die Lizenz kostet den Preis des Entwicklers, 80 k€. Bei gleichem Budget bekommen Sie mit Make eine Person; mit Buy bekommen Sie ein komplettes Produkt, ein ganzes Team, eine Roadmap, die ohne Sie voranschreitet, erprobte Sicherheit und jemanden, der dafür geradesteht. Die Mehrkosten des Make stecken in allen übrigen Zeilen der Tabelle: im Praktikanten, im Audit, in den Tools, in der Fachzeit, in der Code-Übernahme. Insgesamt fast das Doppelte über fünf Jahre, mit Annahmen, die dem "Make" sogar entgegenkommen: ein einziger Entwickler (kein ernsthaftes Projekt hält sich lange mit einem), keine Terminverschiebung, kein technischer Umbau unterwegs, und ein einziger Weggang in fünf Jahren. Jede Zeile dieser Tabelle ist anpassbar, und ich lade Sie ein, die Rechnung mit Ihren Zahlen zu wiederholen; die Erfahrung zeigt, dass die Anpassungen selten zugunsten des "Make" ausfallen.

Die drei Zeilen, die der Kopfkostenvoranschlag immer vergisst

Die Fachzeit. Es ist die am meisten unterschätzte Zeile der Tabelle, und in der Realität oft die größte. Ein internes Tool kommt nur voran, wenn das Fachteam erklärt, entscheidet, testet und erneut testet. Jede Stunde, die ein Partner oder eine CFO damit verbringt, eine Berechnungsregel zu präzisieren oder einen Entwurf freizugeben, ist eine Stunde, die von Deals, LPs und Beteiligungen abgezogen wird. Das ist das Defokus-Risiko: Die wahren Kosten des Make stehen nicht im Budget, sie stehen im Kalender der bestbezahlten Personen des Hauses.

Der Busfaktor, Private-Equity-Ausgabe. Ihr Entwickler, über die Monate zum einzigen Menschen geworden, der den Code versteht, erhält eines Tages ein Angebot vom GP gegenüber. Er geht mit dem einzigen Gehirn, das weiß, warum Zeile 4.218 unter keinen Umständen verändert werden darf. Die Übernahme eines Codes durch einen Neuling ist teuer, wenn sie überhaupt möglich ist; manchmal endet sie in einer Neuentwicklung. Der Praktikant seinerseits war brillant, aber im September wieder an der Hochschule.

Die Design-Expertise. Ein spezialisierter Anbieter liefert nicht nur Code: Er liefert ein Produkt, geformt von Dutzenden Kunden desselben Metiers, die Ihre Probleme vor Ihnen hatten, die regulatorischen Grenzfälle, die Versionswechsel, die erprobte Sicherheit, die DSGVO mit Werkzeugkasten. Intern wird jede Lektion ein weiteres Mal bezahlt, live, auf Ihren eigenen Daten. Und erinnern wir an die MIT-Zahl zu internen Projekten generativer KI: 95% der Piloten erzeugen keinerlei messbaren Effekt auf die Gewinn- und Verlustrechnung [2]. Das eigene Tool mit einem LLM zu bauen heißt, beide Wetten zu stapeln.

Wann Make trotzdem gerechtfertigt ist

Seien wir ehrlich, denn es gibt legitime Fälle: wenn das Tool IHR zentraler Wettbewerbsvorteil IST (ein proprietäres Analysemodell, das Ihre Investmentthese begründet), wenn kein Marktprodukt einen wirklich singulären Bedarf abdeckt, oder wenn Ihre Größe ein echtes Engineering-Team rechtfertigt, mit mehreren Entwicklern, einem Product Manager und einem eingeplanten Budget, nicht mit einem einsamen Entwickler und einem Praktikanten. Make ist ein Beruf; das Problem ist nicht, ihn zu wählen, sondern ihn zu wählen, ohne zu wissen, dass es einer ist.

Der Moment, in dem Sie die Fäden sehen

Inzwischen werden Sie bemerkt haben, dass der Autor dieser Zeilen genau das verkauft: Softwarelizenzen an Fondsgesellschaften. Das ist richtig, und genau deshalb kennt er jede Zeile der Tabelle so gut: Diese Kosten, Administration, Sicherheit, Audits, Roadmap, Versionswechsel, zahlen wir, gebündelt über alle unsere Kunden, statt dass sie ein Einzelner trägt. Das ist die gesamte ökonomische These spezialisierter Software, und sie wurde von den LLMs nicht außer Kraft gesetzt; sie geht sogar gestärkt daraus hervor, denn auch wir entwickeln heute schneller als früher, zum Nutzen derselben Lizenz.

Wenn also das nächste Mal der Zwanzig-Minuten-Prototyp das Gremium verzaubert, stellen Sie eine einzige Frage: Wer wartet ihn in fünf Jahren, und was werden Sie in der Zwischenzeit weniger getan haben? Die Tabelle oben wartet auf Ihre Zahlen.

Zweiter Teil: gewinnt Make in zwei Jahren?

Projizieren wir uns nach vorn, denn der Einwand verdient es, ernst genommen zu werden. In zwei Jahren wird sich die gesamte Wertschöpfungskette der Vermögensverwaltung digitalisiert haben: mehr verarbeitete Flüsse, mehr absorbierte Informationen, mehr Präzision in der Auswahl wie in der Begleitung. Jeder GP wird durch Daten und KI "augmentiert" sein, und diese Augmentierung wird zur Commodity, notwendig, aber nicht mehr hinreichend. Sollte ein GP in dieser Welt nicht, entgegen allem Vorstehenden, massiv in seine Infrastruktur und seine IT investieren? Wird Make am Ende nicht doch gewinnen?

Die Grenze ist nicht fix, sie steigt

Erster Leseschlüssel: Die Make/Buy-Grenze war nie ein Dogma, sie ist eine Linie, die mit dem Abstraktionsniveau steigt. Niemand "macht" mehr seinen Mailserver; jeder "machte" früher seine Excel-Modelle. Die richtige Frage lautet daher nie Make oder Buy im Absoluten, sondern: Wo verläuft die Grenze für meinen Fonds, heute? Und das Paradox der Zwei-Jahres-Projektion ist, dass sie den ersten Teil auf seinem eigenen Terrain stärkt: Wenn Daten- und KI-Werkzeuge zur Commodity werden, dann ist der Nachbau einer Commodity die schlechteste denkbare Investition. Man schafft keinen Wettbewerbsvorteil, indem man nachbaut, was alle besitzen. Die alte Maxime der IT-Leitungen war nie wahrer: make what makes you different, buy what makes you the same.

Das Argument, das brechen kann, und das, was es ersetzt

Seien wir ehrlich über die Schwachstelle: Die gesamte Tabelle des ersten Teils ruht auf den Wartungskosten. Wenn in drei oder fünf Jahren autonome Agenten Code ohne menschliches Zutun warten, korrigieren und weiterentwickeln, erodiert dieses Argument, und Make wird wieder denkbar. Zwei Vorbehalte jedoch. Der erste ist arithmetisch: Die Anbieter profitieren von genau derselben Revolution, und der relative Abstand, gebündelte Kosten über Dutzende Kunden gegenüber allein getragenen Kosten, bleibt bestehen, solange auch nur der geringste Fixkostenblock existiert. Der zweite ist tiefer und unserem Sektor eigen: Ein reguliertes Geschäft wird sein Middle Office nicht auf selbstgeneriertem, ständig wanderndem Code betreiben. Es wird immer jemanden brauchen, der für das System geradesteht: zertifizierte Versionen, Prüfbarkeit, Verantwortungskette. Im Zeitalter der Agenten wird die "Software-Verantwortung" zum Produkt, genau wie die redaktionelle Verantwortung mit Artikel 50 des AI Act zur Trennlinie der Inhalte geworden ist. Was Sie morgen bei einem Anbieter kaufen, ist kein Code mehr: Es ist jemand, der dafür geradesteht.

Buy the platform, make the last mile

Also ja, der GP soll massiv in seine IT investieren, aber nicht in dem Sinn, den die Melodie meint. Das aufzubauende Asset ist nicht das Rohr, sondern das, was hindurchfließt, und das, was es steuert. Drei Schichten, genau. Die proprietären Daten zuerst: Die operativen Daten der Beteiligungen sind eine Lagerstätte, die sonst niemand besitzt, und ihre Golden Source ist mehr wert als jede Entwicklung. Die Doktrin dann: Der Fonds, der seine Prozesse und Investitionsregeln dokumentiert und kodifiziert hat, wird sie von Agenten ausführen lassen können; der Fonds, der sie in den Köpfen der Partner aufbewahrt, nicht. Die governten Schnittstellen schließlich, MCP-Server, die es jedem Agenten erlauben werden, kontrolliert, protokolliert und prüfbar auf diese Daten zu wirken. Die wahrscheinliche Zukunft ist also weder Make noch Buy: Es ist "buy the platform, make the last mile". Die spezialisierte Plattform wird gekauft; die proprietäre Schicht des Fonds, seine Daten, seine Regeln, seine Agenten-Skills, wird darauf gebaut. Das ist eine massive IT-Investition, aber in Daten- und Prozesskapital, nicht in den Nachbau von Rohrleitungen.

Tokenisierung: das Zeitalter des Beweises, Version 2

Dann kommt das Blockchain-Kapitel: KPIs zu verankern, Entscheidungen und ihre zugrunde liegenden Begründungen auf verteilten Registern zeitzustempeln, heißt, die Herkunftslogik, die bereits für Inhalte gilt, auf die Verwaltungsdaten selbst auszudehnen. Nebenbei bemerkt ist die Blockchain das ultimative Buy: Niemand schmiedet seine eigene Kette, man dockt an gemeinschaftliche Standards an. Und auch hier geht der Vorteil an die Fonds, deren Daten bereits zertifiziert und strukturiert sind, bereit, gestempelt zu werden; eine Excel-Datei in vier Versionen tokenisiert man nicht.

What's the next big move?

Wenn alle augmentiert sind, verschwindet das Alpha der Augmentierung, und die Differenzierung fließt dorthin zurück, was sich nicht kommoditisiert. Drei Kandidaten zeichnen sich ab. Der GP als Data Company zuerst: Sein Franchise-Wert wird seine angesammelte private Datenlagerstätte und die darauf verfeinerten Modelle einschließen, etwas, das die LPs irgendwann in der Due Diligence bepreisen werden. Der Übergang von der Entscheidungsunterstützung zur delegierten Ausführung dann: Agenten, die sourcen, Covenants überwachen, Gremien vorbereiten, und deren Wert vollständig von der Qualität der kodifizierten Doktrin abhängt, die man sie anwenden lässt, ein Betriebssystem des Urteilens, das jedem Fonds eigen ist. Die Distribution schließlich: Die Tokenisierung von Fondsanteilen wird die Privatmärkte für kleinere Tickets öffnen und die in Echtzeit verifizierbare Transparenz zu einem Fundraising-Argument machen. In allen drei Szenarien ist der Gewinner nicht, wer sein CRM neu codiert hat. Es ist, wer seine Daten und seine Doktrin kapitalisiert hat.

Fazit

Make or Buy ist im Grunde eine Scheindebatte, und die Zwei-Jahres-Projektion kehrt sie nicht um: Sie verschiebt sie. Die Commodity wird gekauft, heute wie morgen, und morgen erst recht. Gebaut wird, was Sie allein besitzen: Ihre Daten, Ihre Prozesse, Ihre Doktrin. Die eigentliche Frage Ihres nächsten Gremiums lautet daher nicht "Was würde unser Eigenbau kosten?". Sie lautet: "Was besitzen wir, das niemand kaufen kann, und was haben wir dieses Jahr getan, damit es mehr wert wird?"

Quellen

[1] Robert L. Glass, "Facts and Fallacies of Software Engineering", Addison-Wesley, 2002, insbesondere Fakt Nr. 41 zum Anteil der Wartung an den Lebenszykluskosten von Software (40 bis 80% je nach Studie): https://dl.acm.org/doi/book/10.5555/579853

[2] "The GenAI Divide: State of AI in Business 2025", MIT, Projekt NANDA; Zusammenfassung von Fortune: https://finance.yahoo.com/news/mit-report-95-generative-ai-105412686.html