Bilanz: Die Make-vs-Buy-Rechnung ist kaputt

Vier Etappen, rund 25 Stunden fachliche Steuerung, ein System, für das ein klassisches Projekt rund 2'000 Personentage bräuchte. Was das für Kaufentscheide bedeutet und warum der Engpass jetzt das Verstehen ist.

Die klassische Make-vs-Buy-Entscheidung rechnet mit Entwicklungskosten, die es so nicht mehr gibt. Mit KI-gestützter Entwicklung kostet das Herstellen von Software nur noch einen Bruchteil, während Lizenzen und interne Wartung bei gekaufter Software bleiben, wie sie waren. Wer heute noch nach der alten Formel entscheidet, kauft viel zu oft.

Die alte Rechnung

Jahrzehntelang war Kaufen die vernünftige Wahl für alles, was nicht zum Kerngeschäft gehörte. Die Gründe waren gut:

• Herstellkosten: Ein ernsthaftes Fachsystem brauchte ein Team über Jahre. Ein Hersteller verteilte diese Kosten auf viele Kunden.
• Risiko: Eigenentwicklungen liefen notorisch aus Budget und Zeitplan. Ein fertiges Produkt war berechenbar.
• Zeit bis zum Nutzen: Ein gekauftes System lief in Monaten, ein eigenes in Jahren.
• Fachwissen: Der Hersteller kannte Standards und Regulierung besser als das eigene Team.

Alle vier Argumente hängen am selben Punkt: Herstellen war teuer und langsam. Genau dieser Punkt hat sich verschoben.

Was sich verschoben hat

Mit KI-Agenten schreibt ein erfahrener Architekt in Tagen, wofür früher ein Team Monate brauchte. Nicht als Prototyp, sondern mit Tests, Dokumentation und Architekturentscheiden. Damit fällt der grösste Posten der alten Rechnung weg.

Die anderen Posten bleiben dagegen, wo sie waren, und sie lagen schon immer auf der Kaufseite:

• Lizenzen laufen jedes Jahr weiter, oft mit Preiserhöhungen, sobald der Wechsel teuer geworden ist.
• Interne Wartung fällt auch bei gekaufter Software an: Integration, Anpassungen, Releasewechsel, Tests. Selten günstiger als bei eigener Software.
• Abhängigkeit: Roadmap, Datenmodell und Schnittstellen bestimmt der Hersteller.

Für die Hersteller heisst das: Am Herstellen verdienen sie in wenigen Jahren kaum noch etwas. Ihr Wert verschiebt sich zu dem, was sich nicht in Tagen bauen lässt.

Fallbeispiel: ein Zahlungssystem für Echtzeitzahlungen

Im Herbst 2026 haben wir ein teilnehmerseitiges System für Schweizer Instant Payments bauen lassen, nach den offiziellen Implementation Guidelines und ISO 20022. Unsere Rolle war die fachliche und architektonische Steuerung der KI-Agenten: rund 25 Stunden.

Funktional umfasst es Zahlungseingang und -ausgang mit Zustandsautomaten, Rückrufe, Kundenaufträge im Swiss-Payment-Standard, Vier-Augen-Freigaben, Rollen und Mandantenfähigkeit, austauschbare Transporte (Kafka, JMS, HTTP), ein Backoffice, einen Simulator der zentralen Plattform und ein Demo-E-Banking.

Was fehlt, ist bezeichnend: der Anschluss an die echte Plattform und die Zertifizierung. Beides ist keine Frage des Codes.

Der Vergleich ist der eigentliche Punkt. Als klassisches Projekt hätte derselbe Umfang realistisch 1'700 bis 2'800 Personentage gekostet, also 8 bis 10 Personen über 14 bis 20 Monate. Selbst ein eingespieltes Team im Idealfall läge bei 800 bis 1'150 Personentagen.

Die Schätzung stammt aus Erfahrungswerten, hergeleitet über 21 Bausteine und gegengeprüft über die Codemenge bei 10 bis 20 fertigen Zeilen pro Personentag. In keinem Szenario enthalten sind Plattformanschluss, Zertifizierung, Kernbankenadapter, Penetrationstest und produktiver Betrieb.

Der Engpass verschiebt sich vom Programmieren zum Verstehen

Die 25 Stunden funktionierten nur, weil sie jemand mit 15 Jahren Erfahrung im Zahlungsverkehr gesteuert hat. Die Agenten schreiben den Code. Welche Sonderfälle es gibt, wann eine Zahlung als unklar gilt und wie eine Rückforderung korrekt abläuft, müssen sie gesagt bekommen.

Mit denselben Werkzeugen hätte jemand ohne dieses Wissen in 25 Stunden ein System gebaut, das überzeugend aussieht und an den Rändern bricht. Genau dort, wo es im Zahlungsverkehr teuer wird.

Daraus folgt eine unbequeme Verschiebung:

• Fachwissen und Architektur werden zum knappsten Gut. Wer beides hat, wird um ein Vielfaches produktiver.
• Reines Programmieren verliert an Wert. Es ist nicht mehr der Engpass.
• Organisationen brauchen weniger Entwicklerinnen und Entwickler pro System, aber mehr Leute, die Anforderungen präzise fassen, Architektur entscheiden und Ergebnisse fachlich prüfen können.

Die Make-Entscheidung hängt damit weniger am Budget als an der Frage, ob ein Unternehmen diese Menschen hat oder gewinnen kann.

Wo Kaufen weiterhin gewinnt

Buy verschwindet nicht, es wird zur Ausnahme mit klaren Gründen. Gekauft wird künftig, was sich nicht in Code ausdrücken lässt:

• Zertifizierung und Zulassung: Wenn eine Plattform nur zertifizierte Teilnehmer zulässt, ist das Zertifikat das Produkt, nicht die Software.
• Haftung: Wo ein Hersteller für Fehler einsteht, kauft man ein Stück Risiko ab.
• Netzwerkeffekte: Systeme, deren Wert in der Zahl der Teilnehmer liegt, lassen sich nicht nachbauen.
• Betrieb rund um die Uhr: Wer kein eigenes Betriebsteam will, kauft Betrieb, nicht Code. Dann aber besser als Service als eine Lizenz plus eigene Wartung.

Die neue Rechnung

Die Standardfrage dreht sich um: Nicht mehr «Warum sollten wir selbst bauen?», sondern «Was genau kaufen wir, das wir nicht in Wochen selbst haben könnten?»

Die Voraussetzung dafür ist keine Technologie, sondern eine Fähigkeit: Menschen, die Architektur, Fachlichkeit und KI-gestützte Entwicklung zusammenbringen. Wer diese Leute hat, sollte die meisten Kaufentscheide neu prüfen.

Was das bedeutet

Für Unternehmen: Jeder anstehende Kauf- oder Verlängerungsentscheid verdient eine zweite Rechnung, mit realistischen Herstellkosten von heute statt von vor fünf Jahren. Oft wird Kaufen trotzdem richtig sein, aber deutlich seltener als heute.

Für Hersteller: Wer nur Software verkauft, verkauft bald etwas, das Kunden selbst haben können. Überleben werden Anbieter, die Zertifizierung, Haftung, Betrieb oder ein Netzwerk liefern.

Make vs. Buy ist nicht tot. Aber die Rechnung, nach der wir zwanzig Jahre lang entschieden haben, stimmt nicht mehr.