Pecugate: von der Idee zur produktiven Software

Im letzten Beitrag habe ich behauptet, das Codieren sei nicht mehr der schwierige Teil. Solche Sätze sind billig, solange man sie nicht an einem echten Projekt zeigt. Also zeige ich eines: Pecugate, das erste vollständig mit Claude umgesetzte Projekt der Schoeberli AG.

Worum es geht

Pecugate ist eine Portfolio-Software für Schweizer Privatanleger, die in Barrier Reverse Convertibles investieren. Wer diese Produkte kennt, weiss, warum es die Software braucht. Ein BRC ist kein Wertpapier, das man einfach im Depot liegen hat und dessen Kurs man ablesen kann. Er hat eine Barriere, einen Coupon, einen Beobachtungszeitraum, einen oder mehrere Basiswerte, ein Verfallsdatum und eine Rückzahlungslogik, die davon abhängt, ob die Barriere während der Laufzeit berührt wurde.

Wer fünf oder zehn dieser Produkte hält, verliert schnell den Überblick darüber, was eigentlich das Risiko im Portfolio ist. Die meisten Anleger, die ich kenne, lösen das mit einer Excel-Tabelle, die sie einmal aufgesetzt und danach nie wieder ganz sauber nachgeführt haben.

Genau da setzt Pecugate an: Termsheets einlesen, die relevanten Parameter herausziehen, das Portfolio daraus zusammensetzen und sichtbar machen, wo man wirklich steht.

Die Analyse war der Aufwand

Ich habe im letzten Beitrag geschrieben, dass die eigentliche Arbeit in der fachlichen Analyse und im Deployment liegt. Pecugate ist der Beleg dafür.

Die Analyse war nicht deshalb aufwendig, weil niemand wüsste, wie ein Barrier Reverse Convertible funktioniert. Sie war aufwendig, weil jede Bank und jeder Emittent ihr Termsheet anders aufbaut. Dieselbe Information steht einmal in einer Tabelle, einmal in einem Fliesstext, einmal in einer Fussnote. Barrieren werden mal absolut angegeben, mal in Prozent des Anfangswerts. Es gibt europäische und amerikanische Barrierebeobachtung, es gibt Autocall-Mechanismen, es gibt Produkte mit mehreren Basiswerten, bei denen der schwächste zählt.

Diese Fälle muss man kennen, bevor man eine Zeile Code schreibt. Und man kennt sie nicht, indem man eine AI fragt, sondern indem man echte Termsheets nebeneinanderlegt und die Unterschiede aufschreibt. Das war der Teil, der Zeit gekostet hat. Nicht das Programmieren.

Der zweite Analyse-Teil war die Frage, was die Software eigentlich beantworten soll. Ein Portfolio anzeigen kann jede Tabelle. Die interessante Frage bei BRCs ist eine andere: Wie nah bin ich an einer Barriere? Was passiert mit meinem Portfolio, wenn ein bestimmter Basiswert um zwanzig Prozent fällt? Welcher Coupon ist wann fällig? Erst als das klar war, war klar, was gebaut wird.

Die Umsetzung

Was ich hier ehrlich sagen muss: Die Umsetzung war der unspektakuläre Teil. Genau das ist der Punkt.

Sobald das Datenmodell stand – was ist ein Produkt, was ist eine Position, was ist ein Basiswert, wie hängen Beobachtungen an einer Position –, entstand die Anwendung in einem Tempo, das mit klassischer Entwicklung nichts mehr zu tun hat. Ansichten, Berechnungen, Importlogik, Tests: alles Dinge, bei denen ich früher Aufwand in Personenwochen geschätzt hätte und die hier nebenbei mitliefen.

Wichtig war dabei etwas, das man leicht unterschätzt: Ich habe die Resultate laufend fachlich geprüft, nicht nur technisch. Eine Barriereberechnung, die durchläuft und einen Wert liefert, ist kein Beweis dafür, dass sie richtig ist. Der Test ist, ob sie bei einem echten Termsheet dasselbe ergibt wie die Rechnung von Hand. Diese Prüfung kann einem niemand abnehmen – und sie ist der eigentliche Wertbeitrag in diesem Modell.

Das Deployment war der zweite Brocken

Der Moment, in dem eine Software läuft, und der Moment, in dem sie produktiv läuft, sind zwei verschiedene Momente. Dazwischen liegen Fragen, die nichts mit Code zu tun haben.

Wo laufen die Daten? Bei Pecugate sprechen wir über Depotinformationen von Privatpersonen. Das ist kein Datensatz, den man irgendwo hinlegt, weil es gerade praktisch ist. Wer Zugriff hat, wie lange etwas aufbewahrt wird, was bei einem Ausfall passiert – das sind Entscheidungen, keine Implementierungsdetails.

Betrieben wird Pecugate auf Microsoft Azure. Diese Entscheidung ist früh gefallen, weil damit ein Teil der Betriebsfragen – Zertifikate, Skalierung, Deployments ohne Ausfall – bereits mitgelöst ist und nicht einzeln gebaut werden muss.

Dazu kommt der ganze unglamouröse Rest: Domain, Zertifikate, Betrieb, Monitoring, Backups, ein Weg für Änderungen, ohne dass beim nächsten Deployment etwas kaputtgeht. Nichts davon ist schwierig im Sinne von intellektuell anspruchsvoll. Alles davon ist Arbeit, die anfällt, und die niemand automatisch für einen erledigt.

Wo es geharzt hat

Drei Dinge, die ich beim nächsten Mal anders machen würde.

Erstens: Zu früh gebaut. Ich habe mit dem Termsheet-Import angefangen, bevor die Sonderfälle vollständig verstanden waren. Das Resultat war Code, der für die Standardfälle sauber funktionierte und bei jedem zweiten realen Termsheet nachgebessert werden musste. Rückblickend hätte ein Tag mehr Analyse mehrere Tage Nacharbeit gespart. Das ist ironisch, weil ich genau das predige.

Zweitens: Die Versuchung, alles zu bauen. Wenn Features fast nichts mehr kosten, entsteht ein neues Problem: Man baut Dinge, weil man sie bauen kann, nicht weil jemand sie braucht. Jedes zusätzliche Feature muss danach betrieben, gewartet und erklärt werden. Die Disziplin, Nein zu sagen, ist in diesem Modell wichtiger geworden, nicht unwichtiger.

Drittens: Prüfen kostet Zeit, und die muss man einplanen. Wenn die Umsetzung von Wochen auf Stunden schrumpft, schrumpft die Prüfung nicht im selben Verhältnis. Die fachliche Verifikation eines Resultats dauert genau so lange wie vorher. Wer das nicht einplant, hat am Ende schnell viel Software und wenig Gewissheit.

Was ich daraus mitnehme

Pecugate hat mir vor allem eines bestätigt: Die Reihenfolge stimmt. Erst verstehen, dann bauen, dann in Betrieb nehmen und die Verantwortung dafür übernehmen. Der mittlere Teil ist heute der kleinste. Die beiden anderen sind es nicht geworden.

Und der wirtschaftliche Effekt ist trotzdem da. Genau weil die Umsetzung so viel weniger wiegt, verschiebt sich die Gesamtrechnung deutlich. Woher diese Ersparnis genau kommt – und woher nicht –, rechne ich in einem der nächsten Beiträge sauber durch.

Im nächsten Beitrag klären wir zuerst einen Begriff, der gerade viel benutzt und selten definiert wird: Vibe Coding. Was das wirklich ist, und was es nicht ist.

👉 Pecugate anschauen: www.pecugate.com

Sie haben ein Vorhaben, das bisher an Zeit oder Budget gescheitert ist? Sprechen Sie mit uns.