Was ein MVP wirklich kostet: Der Denkfehler hinter den meisten Angebots-Preisen

Die falsche Angst: „Software-Projekte laufen immer aus dem Ruder“

Kaum eine Zahl wird in Gesprächen über Software-Budgets so oft zitiert wie „die meisten IT-Projekte scheitern oder sprengen ihr Budget“. Was dabei fast nie mitgeliefert wird: Woher diese Zahl stammt und für welche Art von Projekt sie eigentlich gilt. Die Standish-Group veröffentlicht seit den 1990er-Jahren regelmäßig ihren CHAOS Report, der Software-Projekte in „erfolgreich“, „gefährdet“ und „gescheitert“ einteilt – über alle Projektgrößen gemittelt liegt die Erfolgsquote seit Jahren nur bei etwa einem Drittel. Genau dieser gemittelte Wert ist es, der als Angst-Statistik in Beratungsgesprächen zirkuliert.

Der entscheidende Teil der CHAOS-Auswertungen wird dabei fast immer weggelassen: Nach Projektgröße aufgeschlüsselt klafft die Erfolgsquote massiv auseinander – kleine, klar geschnittene Projekte erreichen Erfolgsquoten um die 90 Prozent, große Projekte dagegen unter 10 Prozent. Das ist kein graduelles Gefälle, sondern ein Bruch. Wer die gemittelte Horrorzahl auf die Entscheidung für einen ersten Prototyp anwendet, überträgt eine Statistik auf eine Situation, für die sie nicht erhoben wurde.

Was bei großen IT-Projekten wirklich schiefgeht – und warum das ein anderer Fall ist

Die zweite oft zitierte Studie zu Kostenexplosionen stammt von McKinsey und der Universität Oxford (2012, über 5.400 untersuchte IT-Projekte): Großprojekte ab 15 Millionen US-Dollar Startbudget liefen im Schnitt 45 Prozent über Budget, 7 Prozent über Zeit und lieferten 56 Prozent weniger Wert als geplant. Besonders aufschlussreich ist ein Detail, das selten zitiert wird: Jedes zusätzliche Jahr Projektlaufzeit erhöhte die Kostenüberschreitung um weitere 15 Prozentpunkte. 17 Prozent der untersuchten Projekte gerieten so weit außer Kontrolle (200 bis 400 Prozent Budgetüberschreitung), dass sie laut der Studie das Fortbestehen des jeweiligen Unternehmens gefährdeten.

Diese Zahlen beschreiben einen strukturell anderen Mechanismus als einen MVP: Bei mehrjährigen Großprojekten türmt sich Komplexität über die Zeit auf – neue Stakeholder, veränderte Anforderungen, technische Schulden, die sich gegenseitig verstärken. Ein MVP-Sprint läuft dagegen typischerweise wenige Wochen. Die Erkenntnis daraus ist nicht „MVPs sind automatisch sicher“, sondern: Wer sich vor MVP-Kosten fürchtet, sollte sich nicht an Zahlen orientieren, die aus einer völlig anderen Risikokategorie stammen.

Der eigentliche Treiber bei MVPs: nicht Technik, sondern Scope

Wenn nicht die technische Komplexität das Budget sprengt, was dann? Branchenauswertungen zu MVP- und Startup-Entwicklung zeigen ein konsistentes Muster: Feature Creep – während der Umsetzung neu hinzukommende Anforderungen – gilt dort übereinstimmend als der mit Abstand häufigste Grund für Budgetüberschreitungen, mit durchschnittlich rund 27 Prozent Mehrkosten gegenüber dem ursprünglichen Angebot. Umgekehrt berichten Teams, die vor Projektstart eine formale Priorisierung der Kernfunktionen durchführen, im Schnitt 20 bis 40 Prozent niedrigere Gesamtkosten – bei vergleichbarem Ergebnis.

Der Mechanismus dahinter ist unspektakulär, aber wichtig zu verstehen: Jede nachträgliche „können wir nicht noch schnell…“-Anfrage kostet in der Praxis nicht nur die Zeit für die neue Funktion selbst, sondern erzeugt neue Abhängigkeiten und neue Testfälle, die sich mit bereits gebauten Teilen überschneiden. Das ist der eigentliche Grund, warum kleine Änderungswünsche in der Wahrnehmung „nur eine Kleinigkeit“ sind, in der Rechnung aber überproportional zu Buche schlagen.

Was ein Festpreis-Angebot wirklich einpreist

Genau hier setzt ein Mechanismus an, der in den seltensten Angebotsgesprächen offen benannt wird. Mehrere unabhängige Analysen zu Vertragsmodellen in der Softwareentwicklung kommen übereinstimmend zu einem Muster: Anbieter kalkulieren in ein Festpreis-Angebot eine Risikoprämie von häufig 15 bis 50 Prozent auf die reine Umsetzungsschätzung ein – als Puffer gegen genau die Scope-Unklarheit, die zu Vertragsbeginn noch besteht. Bei klar definierten, gut abgegrenzten Projekten liegt Festpreis laut denselben Auswertungen tendenziell rund 10 bis 15 Prozent günstiger als eine Abrechnung nach Aufwand; bei Projekten mit noch unklarem oder sich entwickelndem Umfang kehrt sich das um – dort ist Aufwandsabrechnung häufig um 20 bis 40 Prozent günstiger, weil dort keine Unsicherheits-Prämie „auf Vorrat“ bezahlt wird.

Die Konsequenz ist einfach zu formulieren, aber selten so klar ausgesprochen: Ein Festpreis ist wirtschaftlich betrachtet eine Versicherung. Wie bei jeder Versicherung bestimmt die eingeschätzte Risikohöhe die Prämie – und die Risikohöhe bei einem MVP-Angebot bemisst sich fast ausschließlich daran, wie klar der Anbieter den tatsächlichen Umfang zum Zeitpunkt der Kalkulation einschätzen kann.

Der Denkfehler, der daraus folgt

Daraus ergibt sich eine Umkehrung, die den meisten Preisvergleichen fehlt: Ein auffällig hoher oder „aufgeblähter“ wirkender Festpreis ist nicht in erster Linie ein Zeichen für einen gierigen oder unerfahrenen Anbieter. Er ist häufiger ein Messwert dafür, wie viel Unklarheit über den eigenen Umfang noch im Raum steht, wenn das Angebot erstellt wird. Ein seriöser Anbieter, der ehrlich kalkuliert, muss diese Unklarheit einpreisen – alles andere wäre für ihn selbst wirtschaftlich riskant. Der Denkfehler liegt darin, bei einem hohen Angebot zuerst nach einem günstigeren Anbieter zu suchen, statt zuerst die eigene Anforderung zu schärfen, die diesen Preis mitverursacht hat.

Umgekehrt gilt: Wer vor dem ersten Angebot bereits selbst eine harte Priorisierung vornimmt – was ist Kern, was ist „später“ –, verändert damit direkt die Risikorechnung des Anbieters und damit den Preis. Das ist kein Verhandlungstrick, sondern eine direkte Folge davon, wie Risikoprämien rechnerisch entstehen.

Löst KI dieses Problem? Die Datenlage sagt: nicht das eigentliche

Die naheliegende Erwartung lautet: Wenn KI-Coding-Tools die Entwicklung beschleunigen, müssten MVP-Kosten in den letzten Jahren spürbar gesunken sein. Eine aktuelle, methodisch belastbare Studie widerspricht dieser Intuition deutlich. METR, eine auf KI-Bewertung spezialisierte Forschungsorganisation, führte Anfang 2025 eine randomisierte kontrollierte Studie mit erfahrenen Open-Source-Entwicklern durch: Mit KI-Unterstützung brauchten sie im Schnitt 19 Prozent länger für ihre Aufgaben als ohne – obwohl sie sich subjektiv rund 20 Prozent schneller fühlten. Diese Lücke zwischen gefühlter und tatsächlich gemessener Produktivität ist selbst Gegenstand laufender Forschung.

Andere aktuelle Auswertungen zu KI-Coding-Assistenten zeichnen ein differenzierteres, aber ähnliches Bild: Produktivitätsgewinne von 20 bis 30 Prozent lassen sich zeigen, konzentrieren sich aber stark auf bestimmte, gut abgegrenzte Arbeitsschritte – nicht gleichmäßig über ein Projekt verteilt. (Dieses Muster einer „gezackten Grenze“ zwischen Aufgaben, die KI gut löst, und ähnlich aussehenden Aufgaben, die sie zuverlässig nicht löst, haben wir bereits in einem früheren Artikel eingeordnet.) Besonders aufschlussreich für die MVP-Frage: KI-Agenten brechen bei Mehrdeutigkeiten, die Geschäftskontext, Architekturentscheidungen oder Wissen außerhalb des reinen Codes erfordern, regelmäßig ab oder markieren die Stelle als klärungsbedürftig – sie lösen die Mehrdeutigkeit nicht, sie zeigen sie nur an.

Damit lässt sich die Frage aus der Überschrift präzise beantworten: KI-Tools verbilligen tendenziell die Ausführung – das Schreiben von Code für bereits klar definierte, wiederkehrende Aufgaben. Sie verbilligen nicht die Klärung – das Verstehen, was genau gebaut werden soll. Nach den Daten aus den vorherigen Abschnitten ist aber die Klärung, nicht die Ausführung, der eigentliche Kostentreiber bei MVPs. KI-Tools optimieren damit für die meisten MVP-Budgets nicht den Engpass, der die Kosten tatsächlich bestimmt.

Was das für deine MVP-Kalkulation bedeutet

Aus den vier vorangegangenen Abschnitten lässt sich ein Rahmen ableiten, der sich von der üblichen Kosten-Diskussion unterscheidet – nicht „wie finde ich den günstigsten Anbieter“, sondern „wie senke ich die Risikoprämie, die jeder seriöse Anbieter einpreisen muss“:

• Vergiss die Großprojekt-Horrorzahlen für deine MVP-Entscheidung: Sie stammen aus einer anderen Risikokategorie mit anderer Fehlermechanik (Komplexität über Jahre) als ein Wochen-Sprint (Scope-Klarheit zu Beginn).
• Priorisiere hart, bevor du ein Angebot einholst: Was ist der eine Kern, den der erste Prototyp beweisen muss? Alles andere ist „später“ – das ist der wirksamste Hebel, nicht die Anbieterwahl.
• Lies einen hohen Festpreis als Signal, nicht nur als Zahl: Ein auffällig hoher Preis zeigt oft, wo aus Anbietersicht noch Unklarheit besteht – genau dort lohnt sich eine zweite Klärungsrunde, bevor verhandelt wird.
• Erwarte von KI-Tools keine Kostenhalbierung: Sie helfen dort, wo der Umfang schon klar ist – nicht dabei, ihn klarzumachen. Das bleibt Arbeit, die vor dem eigentlichen Bauen passieren muss.

Keiner dieser Punkte ersetzt eine konkrete Kalkulation für ein bestimmtes Vorhaben – dafür braucht es die tatsächlichen Eckdaten der Idee. Was sich aber klar sagen lässt: Ein strukturierter Klärungsschritt vor der Preisfindung ist kein zusätzlicher Aufwand on top des Budgets, sondern der Grund, warum das Budget danach überhaupt belastbar ist.