Plattform oder Code: Warum bei der Werkzeug-Entscheidung die falsche Frage zuerst kommt

Nicht die Plattform entscheidet über das richtige Werkzeug, sondern der erwartete Nettonutzen des Prozesses – und der ist etwas anderes als die Summenzeile der Wirtschaftlichkeitsrechnung. Über die Bauweise entscheiden anschließend fünf nüchterne Prozesseigenschaften, kein Funktionsvergleich.

Design-to-Cost dreht die übliche Logik um: Der Nettojahresnutzen bemisst den vertretbaren Aufwand, nicht der technisch mögliche Aufwand die Erwartung. Drei Größenklassen ordnen das: Unter etwa 5.000 Euro bleibt es bei Ordner, Prompt-Datei und Vorlage; bis etwa 50.000 Euro trägt ein konfigurierter Ablauf auf einer vorhandenen Plattform; darüber rechtfertigt sich ein gebautes Werkzeug mit eigener Oberfläche und eigenem Betrieb. Die obere Schwelle ist keine feste Zahl, sondern die Mitte dessen, was ein Erstaufbau von 0,3 bis 1,0 Personenjahren in höchstens zwei Jahren tragen muss. Im Leitbeispiel des Buchs liegt der Nettonutzen bei 34.000 bis 53.000 Euro – nicht bei den 75.000 Euro der Summenzeile, die die Pflege- und Plattformkosten noch nicht abzieht. Er landet damit genau auf der Grenze zwischen konfiguriertem Ablauf und Eigenentwicklung, und fünf Kriterien – Zahl der Läufe, Änderungshäufigkeit, Anbindungsbedarf, Kompetenz, Betriebsverantwortung – entscheiden sie zugunsten der Plattform.

Wer dabei mit einer KI-gestützten Beschleunigung der Eigenentwicklung rechnet, sollte vorsichtig sein. Die methodisch sauberste Untersuchung dazu, ein randomisiertes Experiment der Forschungsorganisation METR mit 16 erfahrenen Entwicklern an 246 realen Aufgaben, kam 2025 zu einem Gegenteil-Befund: Mit KI-Werkzeug brauchten die Entwickler 19 Prozent länger – erwartet hatten sie vorher eine Beschleunigung um 24 Prozent, und selbst danach glaubten sie noch, 20 Prozent schneller gewesen zu sein. Als METR die Untersuchung 2026 wiederholte, lehnten so viele Entwickler die Teilnahme ab, weil sie nicht mehr ohne KI arbeiten wollten, dass die Forscher ihre eigenen neuen Daten für unzuverlässig erklärten. Für die Wahl zwischen Low-Code und Eigenentwicklung ist das eine Erleichterung: Sie brauchen diesen Faktor nicht. Entscheidend bleibt ein Architekturkriterium: Der Kontext-Ordner bleibt außerhalb des Werkzeugs, Prompts bleiben versionierte Dateien.

→ Mehr zum Buch und zum Kapitel „Das Werkzeug bauen: Low-Code oder KI-gestützte Entwicklung”