„Was kostet das Ganze — fix?" Das ist die verständlichste Frage der Welt, wenn du ein Softwareprojekt beauftragst. Und sie führt zu einer der häufigsten Fehlentscheidungen im Mittelstand. Nicht weil Festpreis schlecht wäre. Sondern weil die Wahl zwischen Festpreis und agil fast immer aus dem falschen Grund getroffen wird: aus dem Wunsch nach Sicherheit statt aus der Natur des Projekts.
Dieser Beitrag stellt beide Modelle ehrlich gegenüber — inklusive der unbequemen Wahrheit, dass der Festpreis dir oft genau die Sicherheit verkauft, die er nicht liefern kann.
Festpreis heißt: Du beschreibst vorab möglichst genau, was gebaut werden soll, und der Anbieter nennt einen festen Preis dafür. Das Risiko der Schätzung liegt beim Anbieter — scheinbar.
Agil heißt: Ihr definiert die Richtung und das Budget pro Zeitabschnitt, baut in kurzen Zyklen, schaut nach jedem Zyklus drauf und steuert nach. Das Risiko wird geteilt und laufend sichtbar gemacht.
Der Kern des Unterschieds ist nicht der Preis. Es ist der Umgang mit einer einzigen Frage: Wie sicher weißt du heute schon, was du in sechs Monaten genau brauchst?
Wenn die Antwort „sehr sicher" ist — ein klar umrissenes, stabiles Problem — ist Festpreis ein faires, sinnvolles Modell. Wenn die Antwort ehrlich „nicht so genau" ist, verkauft dir der Festpreis eine Sicherheit, die nur auf dem Papier existiert.
Ein Festpreis erfordert eine vollständige Spezifikation vorab. Niemand kann einen festen Preis für etwas nennen, das nicht beschrieben ist. Das klingt nach Disziplin — ist aber bei den meisten Projekten eine Illusion.
Denn die Spezifikation, die du am Anfang schreibst, ist genau die, von der du am wenigsten verstehst. Du beschreibst Software, die du noch nie benutzt hast, für einen Prozess, den du erst beim Bauen wirklich durchdenkst. Drei Dinge passieren dann fast immer:
Das ist keine Anklage gegen den Festpreis. Es ist die ehrliche Beschreibung dessen, was er ist: ein Modell, das nur funktioniert, wenn die Spezifikation wirklich stabil ist. Bei einem klar umrissenen, abgegrenzten Stück Software ist das der Fall — und dann ist der Festpreis exzellent.
Agil ist nicht das automatisch bessere Modell, und es wird oft genauso missbraucht.
Agil ohne Disziplin ist nur teures Trial-and-Error. Wenn niemand priorisiert, wenn das Budget nicht überwacht wird, wenn jeder Sprint die Richtung wechselt, dann ist „agil" nur ein hübsches Wort für ein Projekt ohne Steuer.
Agil verlangt deine Mitarbeit. Im Festpreis kannst du theoretisch die Spec abgeben und warten. Agil funktioniert nur, wenn auf deiner Seite jemand regelmäßig Entscheidungen trifft und Prioritäten setzt. Wer diese Zeit nicht hat, wird mit agil unglücklich.
Agil macht das Budget transparent — und das ist unbequem. Du siehst laufend, was Dinge wirklich kosten. Das ist ehrlich, fühlt sich aber weniger nach Sicherheit an als eine Zahl im Vertrag — auch wenn diese Zahl oft fiktiv ist.
Der ehrliche Punkt: Agil verlagert die Sicherheit von „Zahl im Vertrag" zu „Kontrolle im Prozess". Das ist für viele Mittelständler ungewohnt — aber bei unsicheren Anforderungen die ehrlichere und am Ende günstigere Variante.
In der Praxis ist die beste Antwort selten reines Schwarz oder Weiß. Wir empfehlen mittelständischen Kunden häufig eine Kombination:
Festpreis für die Discovery. Ein klar abgegrenzter, fester Preis für die erste Phase: Prozess verstehen, Risiken aufdecken, das erste echte Inkrement definieren. Das ist gut schätzbar und gibt dir eine ehrliche Entscheidungsgrundlage, bevor du das große Budget freigibst.
Agil mit Budget-Deckel für die Umsetzung. Danach iterativ bauen, aber mit einem klar vereinbarten Maximalbudget und festen Steuerungspunkten. Du bekommst die Flexibilität von agil und die Planbarkeit eines Deckels.
Dieses Modell nimmt beiden Welten das Schlechteste und behält das Beste: keine fiktive Gesamtspezifikation, aber auch kein offenes Fass. Es passt zur Logik, die wir im Leitfaden zur individuellen Softwareentwicklung für seriöse Projekte beschreiben — früh sichtbar liefern, Risiken früh aufdecken.
Wenn dein Projekt stark von Schnittstellen abhängt, ist diese Stufung besonders sinnvoll: Schnittstellenrisiken zeigen sich erst beim Bauen. Mehr dazu in API-Entwicklung in München. Und wenn ein Altsystem im Spiel ist, lies ergänzend Legacy-Modernisierung — dort ist ein reiner Festpreis fast immer die falsche Wahl.
Mehr zu unserem Vorgehen findest du auf der Seite zur individuellen Software- und App-Entwicklung.
Festpreis oder agil ist keine Glaubensfrage. Es ist eine Frage, wie sicher du heute weißt, was du brauchst. Festpreis ist exzellent für stabile, klar abgegrenzte Probleme. Agil ist ehrlicher, wenn die Anforderungen erst beim Bauen reifen. Der häufigste Fehler ist die Wahl aus dem Wunsch nach Sicherheit statt aus der Natur des Projekts.
Du weißt nicht, ob dein Vorhaben ein Festpreis-Fall ist oder iterativ laufen sollte? Wir schauen mit dir auf die Anforderungen und sagen ehrlich, welches Modell dich weniger kostet — auch wenn das nicht das ist, was sich sicherer anfühlt.
Dieser Beitrag beruht überwiegend auf eigener Projekterfahrung aus Festpreis- und agilen Projekten im Raum München. Wo wir das agile Modell beschreiben, beziehen wir uns auf dessen ursprüngliche Definition; die Primärquellen sind unten verlinkt. Es werden bewusst keine externen Studien-Statistiken zitiert.
