Pretto: Wie man zwischen Build und Buy entscheidet, um effektiv zu skalieren

Pretto ist ein französisches Fintech-Unternehmen, das auf Hypothekenvermittlung spezialisiert ist. Seit seiner Gründung vor 8 Jahren hat es die Spielregeln eines stark regulierten Sektors durch einen 100 % digitalen Ansatz weitgehend auf den Kopf gestellt. Und 2021 wurde mit dem Start eines Netzwerks unabhängiger Agenten ein neuer Meilenstein erreicht.

Heute teilt sich die Aktivität zwischen Kunden, die remote betreut werden, und solchen, die von den 300 angeschlossenen Agenten unterstützt werden. Diese Entwicklung stützte sich auf eine zentrale Herausforderung: ein effizientes, modernes und einheitliches Tool-Paket anzubieten. Eine strategische Frage stellte sich daher schnell: Sollen diese Tools intern entwickelt oder auf bestehende externe Lösungen zurückgegriffen werden? Heute laden wir Sie ein, das Interview mit François Sevaistre, CTO von Pretto, zu entdecken.

In einem Fintech wie Pretto, wo Regulierung und Ausführungsgeschwindigkeit entscheidend sind, welche Kriterien leiten Ihre Entscheidungen zwischen Build und Buy?

François Sevaistre: Wir kehren immer zu zwei einfachen Kriterien zurück:

1. Ist die betreffende Komponente ein Wertglied, das wir unseren Kunden direkt bringen?
2. Hat sie Einfluss auf unser Markenimage und die Nutzererfahrung?

Wenn die Antwort ja lautet, bevorzugen wir Build.

Das war bei unserem CRM der Fall. Wir wollten eine einheitliche und moderne Nutzererfahrung bieten. Der Agent muss in der Lage sein, seine Kunden zu verwalten, seine Interessenten zu verfolgen, seine Dateien zu erstellen... und das alles in einem kohärenten Produktuniversum mit einfacher Ergonomie. Hätten wir eine externe Lösung wie SugarCRM gekauft oder Salesforce weiter angepasst, hätten wir variable Kosten gehabt, die mit dem Netzwerk wachsen, und eine starke Abhängigkeit von einer eingeschränkten Umgebung.

Wir hatten Salesforce bereits stark angepasst und wussten, dass wir sowieso spezifischen Code schreiben müssten. Unter diesen Bedingungen war es besser, intern zu bauen, in unserer eigenen Logik, anstatt Drittanbieterlösungen zu stapeln.

Schließlich gab es ein langfristiges finanzielles Problem: Anfangs kostet Build mehr als eine SaaS-Lizenz, aber sobald die Investition getätigt ist, werden die Kosten geglättet und sinken, wenn die Aktivität skaliert.

Hatte diese organisatorische Entscheidung Auswirkungen auf Ihre Tech-Teams?

François Sevaistre: Ja, und es ist sogar zentral für unsere Philosophie. Wir sind ein kleines Tech-Team. Wir wollten immer schlank bleiben, mit Entwicklern, die für ein ganzes Stück des Stacks verantwortlich sind.

Als wir uns entschieden, unser CRM zu bauen, stellte ich einen Manager und zwei Engineers ein: Sie hatten die volle Verantwortung für diese Komponente. Ihre Mission reichte vom Design bis zur Auslieferung, einschließlich technischer Entscheidungen. Dieses Empowerment-Modell verändert alles: Sie sind keine bloßen "Ticket-Bearbeiter", sondern Engineers, die die Bedürfnisse verstehen, an Diskussionen mit Produkt und Design teilnehmen und die besten Lösungen vorschlagen.

Das ist ein wichtiger Faktor für die Mitarbeiterbindung. Ein Entwickler, der nur ausführt, wird irgendwann müde und verlässt das Unternehmen. Ein Engineer hingegen, der als verantwortlich für einen Bereich identifiziert wird, sieht seinen konkreten Einfluss auf das Geschäft. Das ist viel befriedigender.

Wie wurde die Entscheidung konkret getroffen?

François Sevaistre: Sie erfolgte in zwei Phasen. Zunächst: Sollen wir kaufen oder bauen? Dieser erste Schritt betraf alle: Business, Produkt, Tech, Design... und sogar zukünftige Nutzer, die Agenten. Wir tauschten uns mit ihnen aus, um ihre Erwartungen zu verstehen und Bedürfnisse zu priorisieren. Ihre Beteiligung stärkte die Relevanz unserer Entscheidung.

Dann, sobald die Entscheidung zum Bauen gefallen war, mussten wir den technischen Stack festlegen. Das war eine rein technische Entscheidung mit der Richtlinie: etwas Einfaches, Leichtes und Wartbares bauen.

Drei Jahre später: Was ist Ihre Bilanz?

François Sevaistre: Die Bilanz ist positiv. Heute arbeiten mehr als 300 Agenten täglich mit diesem Tool. Es ist buchstäblich ihr Lebensunterhalt, da sie nur auf Provisionsbasis bezahlt werden. Es war daher entscheidend, dass das Tool robust, zuverlässig und ergonomisch ist.

Wir entwickeln es weiter und integrieren zum Beispiel KI-basierte Features. Aber wir achten immer auf eine Sache: Ein Feature, so beeindruckend es auch sein mag, ist nutzlos, wenn es nicht genutzt wird. Die eigentliche Herausforderung besteht darin, Features an der richtigen Stelle zu platzieren, sodass ihre Akzeptanz natürlich ist.

Finanziell ist klar, dass wir in dieser Phase mehr bezahlt haben, als wenn wir Salesforce-Lizenzen genommen hätten. Aber die Nutzererfahrung ist viel besser, und die Akzeptanz ist unvergleichlich. Wenn Sie Broker einstellen, die zuvor mit Stift und Papier gearbeitet haben, ist jede gesparte Trainingsstunde Gold wert.

Welche Komponenten betrachten Sie umgekehrt als nicht differenzierend und damit auslagerbar?

François Sevaistre: Es gibt mehrere.

• KI: Wir trainieren kein eigenes LLM, das ist nicht unser Kerngeschäft. Um unsere Prompts und ihre Versionierung zu verwalten, nutzen wir Langfuse.

• Datenpipeline: Wir haben Segment, um Nutzerereignisse zu sammeln und weiterzuleiten. Im Moment kaufen wir, aber angesichts der Kosten denken wir darüber nach, es zu internalisieren.

• E-Mail-Versand: Wir nutzen noch ein Stück Salesforce, um E-Mails an die richtigen Kunden zu routen. Es ist teuer und wahrscheinlich dazu bestimmt, intern neu aufgebaut zu werden.

Zusammenfassend lässt sich sagen: Alles, was unseren Kunden keinen direkt differenzierenden Wert bringt, kann eingekauft werden.

Welchen Rat würden Sie einem CTO geben, der zwischen Build und Buy schwankt?

François Sevaistre: Jede Zeile Code, die Sie schreiben, ist Wartungsschuld. Wenn Sie also auslagern können, tun Sie es. Buy ist ein ausgezeichneter Weg, einen Use Case schnell zu testen. Wenn es nicht funktioniert, ist ein Wechsel einfach.

Die eigentliche Falle ist, zu früh zu bauen. Sobald Sie intern investiert haben, verteidigen Sie Ihre Lösung, auch wenn sie nicht mehr den Bedürfnissen entspricht. Mit einer gekauften Lösung hingegen behalten Sie die Freiheit, sich neu auszurichten.

Mein Rat: Beginnen Sie mit dem Kauf, validieren Sie den Bedarf, und bauen Sie dann nur das, was wirklich strategisch für Ihr Unternehmen ist.